Extend time range bucketing attributes to retrievers#136072
Extend time range bucketing attributes to retrievers#136072javanna merged 3 commits intoelastic:mainfrom
Conversation
There's situations where the time range filter is provided as part of the retriever tree. In that case, we capture the time range filter from while parsing it, but we don't do the corresponding introspection of the retriever tree to extract which fields were the time range filters made against. This commit introduces a very basic introspection of retrievers and tests around it.
javanna
added
>enhancement
:Search Foundations/Search
elasticsearchmachine
added
the
Team:Search Foundations
|
Hi @javanna, I've created a changelog YAML for you. |
|
Pinging @elastic/es-search-foundations (Team:Search Foundations) |
| } | ||
| } | ||
|
|
||
| private static void introspectRetriever(RetrieverBuilder retrieverBuilder, QueryMetadataBuilder queryMetadataBuilder, int level) { |
There was a problem hiding this comment.
I am not particularly happy about having to make this change. I think that retrievers with a time range filter are a bit of an edge case that is not so important for our current metrics effort around search performance.
That said, this change is required to avoid weird discrepancies due to the very general way that we track the time range filter from, without extensive knowledge of where we get it from. We could disable tracking it in certain situations as an alternative, but retrievers get rewritten to ordinary queries hence at the shard level we don't have the info to be able to make the distinction.
| private static void assertTimeRangeAttributes(List<Measurement> measurements, String target, boolean isSystem) { | ||
| public void testTimeRangeFilterRetrieverOneResult() { | ||
| SearchSourceBuilder searchSourceBuilder = new SearchSourceBuilder(); | ||
| searchSourceBuilder.retriever(new StandardRetrieverBuilder(new RangeQueryBuilder("@timestamp").from("2024-12-01"))); |
There was a problem hiding this comment.
Very nice test, thank you !
3 participants
There's situations where the time range filter is provided as part of the retriever tree. In that case, we capture the time range filter from while parsing it, but we don't do the corresponding introspection of the retriever tree to extract which fields were the time range filters made against.
This commit introduces a very basic introspection of retrievers and tests around it, expanding on #135549.