Carry over release highlights from Lucene 9.1 #85571
Conversation
mayya-sharipova
added
:Search/Search
mayya-sharipova
force-pushed
the
lucene-highlights-9.1
branch
from
7df94ff to
2acb657
Compare
|
|
||
| Counting a number of documents that fall into a certain range could be faster now. | ||
| In {es} we use counting in aggregations (e.g. date range aggregation) and | ||
| for `_count` API. |
There was a problem hiding this comment.
@iverase I am a little fuzzy how describe this change in PointRangeQuery . Can you please confirm this is a valid description.
|
Note, this changes doesn't include "LUCENE-10382: Support filtering in KnnVectorQuery", as we have a corresponding Elasticsearch PR that is marked as release highlight. |
| fields should see these improvements. | ||
|
|
||
| [discrete] | ||
| === Faster "count" searches for Points |
There was a problem hiding this comment.
The count search optimizations that were introduced do not apply to Elasticsearch until we start leveraging the new Weight#count API. However there are speedups for range queries indeed, maybe we could check the sort of improvement that we observed on nightly benchmarks to share a more catchy headline such as "Up to 20% faster range queries". For instance I'm looking at https://elasticsearch-benchmarks.elastic.co/index.html#tracks/noaa/nightly/default/90d where nightly-noaa-add-defaults-range_field_big_range-latency looks like it got a ~35% speedup on 2022-02-22.
There was a problem hiding this comment.
@jpountz Thanks for the suggestion. I will add this point and remove others.
Out of curiosity, which Lucene changes brought up these speedups in range queries? Are they applicable only for range fields or any Point fields?
There was a problem hiding this comment.
Addressed in dc13f58, borrowing from your Lucene updates.
|
@jpountz Can you please have another look at this when you have time. |
|
cc @giladgal |
4 participants
No description provided.