You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We recently added an optimization for top K sorted by time.
We process splits in the most promising order in order.
Once we have saturated the order, if a the split metadata informs us that we cannot hope for better results, we currently set max_hits to 0 which has the great side-effect of removing the need to warmup the timestamp fields.
We however still perform search, because to count the documents.
It would be interesting to add an enum property to the search proto to make it possible to remove the need to process the split entirely, (in the absenve of any aggregations of course)
Disclaimer
Let's not break backward compatibility. Hence the idea of using an enum, which would give us more control on what the default value should be in the absence of a value.
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
We recently added an optimization for top K sorted by time.
We process splits in the most promising order in order.
Once we have saturated the order, if a the split metadata informs us that we cannot hope for better results, we currently set max_hits to 0 which has the great side-effect of removing the need to warmup the timestamp fields.
We however still perform search, because to count the documents.
It would be interesting to add an enum property to the search proto to make it possible to remove the need to process the split entirely, (in the absenve of any aggregations of course)
Disclaimer
Let's not break backward compatibility. Hence the idea of using an enum, which would give us more control on what the default value should be in the absence of a value.
The text was updated successfully, but these errors were encountered: