-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Closed
Labels
:Search Relevance/PercolatorReverse search: find queries that match a documentReverse search: find queries that match a document>enhancementMetaTeam:Search RelevanceMeta label for the Search Relevance team in ElasticsearchMeta label for the Search Relevance team in Elasticsearch
Description
There are several tasks left around from when the percolator was rewritten in 5.0 that can be done in order to improve the percolator's performance.
-
support for selecting percolator query candidate matches containing wildcard / prefix queries.Add support for selecting percolator query candidate matches containing wildcard / prefix queries #25351 - Document how to deal with wildcard and prefix queries. Add best practises for wildcard queries inside percolator queries #27831
- Add support for selecting percolator query candidate matches containing range queries. Add support for selecting percolator query candidate matches containing range queries #25647
- Add support for selecting percolator query candidate matches containing
geo_distance,geo_bounding_box,geo_polygonandgeo_shapequeries. Add support for selecting percolator query candidate matches containing geo_point based queries #26040 - Add support for selecting percolator query candidate matches containing
geo_shapequeries. - Today the percolator query's xcontent representation is stored. Alternatively the percolator could also store the percolator query's
Writablerepresentation. This could speed up percolating because parsing the latter format has less overhead. I expect the this improvement to be more noticeable when a percolator query is somewhat more complex (bool query with several clauses) compared to a simpletermquery. Store the QueryBuilder's Writable representation instead of its XContent representation #25456 -
In case of phrase queries and conjunction queries the percolator only extracts the longest term at index time. The idea here is that only a single term needs to be indexed for the selecting of percolator query candidate matches at search time to work and the longest term is picked because in general that is the rarest term. However that may not always be the case and it would be great if that logic is configurable.Hint what clauses are important in a conjunction query based on fields #26081 (this change has been superseded by Use CoveringQuery to select percolator candidates? #26307) - Change the
percolatequery the accept multiple documents (viadocumentsjson object array). This can speed percolation when many documents need to be percolated. The price for parsing and matching percolator queries is only paid once per batch of documents instead of for each document to percolate. Add support to percolate query to percolate multiple documents simultaneously #26418 - Improve extraction of conjunctions in order to have fewer false positives. Use CoveringQuery to select percolator candidates? #26307
hpetru
Metadata
Metadata
Assignees
Labels
:Search Relevance/PercolatorReverse search: find queries that match a documentReverse search: find queries that match a document>enhancementMetaTeam:Search RelevanceMeta label for the Search Relevance team in ElasticsearchMeta label for the Search Relevance team in Elasticsearch