Optimize lone single bucket date_histogram#71180
Conversation
This restores SQL's test for fetching `half_floats` after we backported the precision change in that fetch (elastic#70653)
This optimizes the `date_histogram` agg when there is a single bucket and no sub-aggregations. We expect this to happen from time to time when the buckets are larger than a day because folks often use "daily" indices. This was already fairly fast, but using the metadata makes it 10x faster. Something like 98ms becomes 7.5ms. Nice if you can get it! Like elastic#69377 this optimization will disable itself if you have document level security enabled or are querying a rollup index. Also like elastic#69377 it won't do anything if there is a top level query.
|
|
Pinging @elastic/es-analytics-geo (Team:Analytics) |
|
run elasticsearch-ci/1 |
not-napoleon
left a comment
There was a problem hiding this comment.
As noted, I think future us will appreciate a little more documentation, but otherwise this looks fine. +1
| if (query instanceof TermQuery) { | ||
| return new TermQueryToFilterAdapter(searcher, key, (TermQuery) query); | ||
| } | ||
| if (query instanceof ConstantScoreQuery) { |
There was a problem hiding this comment.
It seems like an obvious question "Why don't we check for a wrapped TermsQuery or MatchAllDocsQuery?" Would be good to have a comment to answer that.
There was a problem hiding this comment.
Because I've not seen it come up. But, looking at it with fresh eyes now, I think the safest thing is to always unwrap.
| } | ||
| } | ||
|
|
||
| private static class DocValuesFieldExistsAdapter extends QueryToFilterAdapter<DocValuesFieldExistsQuery> { |
There was a problem hiding this comment.
At some point, keeping all the implementations as static inner classes is going to get unwieldy. Do you think we should refactor QueryToFilterAdapeter into its own package and make these static inners top level package private classes?
There was a problem hiding this comment.
Yeah.... I'll see about breaking them out in a mechanical follow up PR.
This optimizes the `date_histogram` agg when there is a single bucket and no sub-aggregations. We expect this to happen from time to time when the buckets are larger than a day because folks often use "daily" indices. This was already fairly fast, but using the metadata makes it 10x faster. Something like 98ms becomes 7.5ms. Nice if you can get it! Like elastic#69377 this optimization will disable itself if you have document level security enabled or are querying a rollup index. Also like elastic#69377 it won't do anything if there is a top level query.
…2989) This optimizes the `date_histogram` agg when there is a single bucket and no sub-aggregations. We expect this to happen from time to time when the buckets are larger than a day because folks often use "daily" indices. This was already fairly fast, but using the metadata makes it 10x faster. Something like 98ms becomes 7.5ms. Nice if you can get it! Like #69377 this optimization will disable itself if you have document level security enabled or are querying a rollup index. Also like #69377 it won't do anything if there is a top level query.
This optimizes the
date_histogramagg when there is a single bucketand no sub-aggregations. We expect this to happen from time to time when
the buckets are larger than a day because folks often use "daily"
indices.
This was already fairly fast, but using the metadata makes it 10x
faster. Something like 98ms becomes 7.5ms. Nice if you can get it!
Like #69377 this optimization will disable itself if you have document
level security enabled or are querying a rollup index. Also like #69377
it won't do anything if there is a top level query.