It seems that the undocumented TERM() operator can give quite a performance boost to searches.
E.g. I ran a search on "WINDOWS7$" which is also segmented into "WINDOWS7" and "$".
Running the search as TERM(WINDOWS7$) was 2x faster. Can someone explain what is happening behind the curtain, and why this gem is not mentioned in the documentation?
You can see in lipsy what it's doing in the search.log
maybe have to enable debug not sure
the soon-to-be-documented TERM operator tells Splunk to treat whatever is inside the parenthesis as a single term in the index, even if it contains characters that are usually recognized as breaks or delimiters.
for example, if you searched for "more_coffee", Splunk ends up searching for "more" and "coffee" and post filtering the results.
if you know that the term/phrase "more_coffee" definitely exists in the index, you can force Splunk to find it by using TERM(more_coffee).
i won't speak for the search performance. but, 4.3 handles rare-term searches much more efficiently. (yay bloom filters!)
To further clarify, the reason we can't automatically assume "more_coffee" is in the index is due to the nature of minor breakers like '_'
If you have an event that has something like a_b_c_d
we will index a,b,c,d and a_b_c_d, but not b_c or the like.
Therefore if you search for b_c, we can't assume you don't also want b_c when it occurs inside something like a_b_c_d, which would be excluded if you used TERM(b_c)
Did you have some example timed results? I have been running it on my test 4.3 system and the times appear to be on average around identical between using the two.
Using the search inspector (this is where I also got the search run-time from) it doesn't appear that TERM actually adds anything or removes anything from the search process, it looks to me as if it is interpreted as just containing the required search terms.
It may just be that my test data isn't complex enough to provide any interesting results but I can't find any difference in the search inspector.