I'm used to working with summary indexes and tonight I thought I'd noodle with accelerated searches. My first search looked like this:
sourcetype="cisco_ips_syslog" | stats count by dest_ip
If a subsequent search is:
sourcetype="cisco_ips_syslog" dest_ip="10.1.15.2" | stats count by dest_ip
Will it pull from the accelerated search or will it pull from the raw data? Secondly, if my search is:
sourcetype="cisco_ips_syslog" dest_ip="10.1.15.2" | timechart span=1d count by dest_ip
Will THAT pull from the accelerated search or from the raw data?
My understanding is that searches that draw from the same pool of data before applying transformations will use the same summary. What that means is, as long as the part of the search before the first pipe remains the same as your accelerated search, you can change what follows and still have it be used by the summary. By that logic, neither of the two searches you provide above would qualify to use the summary created for the accelerated search. But this search might:
sourcetype="cisco_ips_syslog" | timechart span=1d count by dest_ip
Of course the best way to find out is to do as martin_mueller suggests in the preceding answer. Run the searches, accelerate them, and see if they get their own summary or are added to the existing summary.
I've tried this myself and unfortunately doesn't seem to work if you include extra search options within in the base search.
I was looking to use report acceleration as a nicer "automatically" managed way to generate pre-report statistics.
I can't seem to nut out any way into which I can put an extra search definition into the most efficient search location (before the pipe) and have it access the report acceleration summary data.
I'd say that's by design - a search can only use a report acceleration if its accelerate-able part matches the accelerated search's part.
For the first example you can put the filter by dest_ip after the stats count by dest_ip. Whether that's faster than just running the search by itself depends on the distribution of data.
The second example cannot really work because the acceleration itself does not need daily timespans, so it likely will not have exact per-day information available.
You can turn things around - accelerate a timechart, and post-process the results you need from that.