New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Warmer (search) to support query cache #7326
Conversation
allow for search based warmer to support query cache flag on the search request, and use the index level query caching flag if set. Note, this change required changing the logic in warmer, to pass the actual searcher that will be used on for the actual search requests to the warmers. This changes the previous behavior of only using readers that were not warmed during merges, or already around. This change simplifies the warmer code significantly, and the overhead will be very small for existing warmed readers (like after a merge), yet allow us to implement warmers like the query cache (and actually have a cleaner contract, "same as search"). closes elastic#7326
@jpountz hey, would for you to look at this, since in order to change that, I ended up changing the warmer logic in which searcher to provide. |
indicesQueryCache.load(request, context, queryPhase); | ||
} else { | ||
queryPhase.execute(context); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These 5 lines are exactly the same as in executeQueryPhase
, maybe this should be extracted to a utility method?
I am worried that this might have significant impact on users who have large shards/lots of warmer queries/complex warmer queries? I wouldn't be surprised that warmer queries often use a |
try and keep the existing only warm new segments, but extend the top warming to also execute in search, also, make methods names a bit more readable
boolean canCache = indicesQueryCache.canCache(request, context); | ||
// early terminate when we can cache, since we can only do proper caching on top level searcher | ||
// also, if we can't cache, and its top, we don't need to execute it, since we already did when its not top | ||
if ((canCache && !top) || (!canCache && top)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a complicated way to say if (canCache != top)
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
aye :)
LGTM, I just left minor (costmetics) comments |
allow for search based warmer to support query cache flag on the search request, and use the index level query caching flag if set. closes #7326
allow for search based warmer to support query cache flag on the search request, and use the index level query caching flag if set. closes #7326
allow for search based warmer to support query cache flag on the search request, and use the index level query caching flag if set.
Note, this change required changing the logic in warmer, to pass the actual searcher that will be used on for the actual search requests to the warmers. This changes the previous behavior of only using readers that were not warmed during merges, or already around. This change simplifies the warmer code significantly, and the overhead will be very small for existing warmed readers (like after a merge), yet allow us to implement warmers like the query cache (and actually have a cleaner contract, "same as search").