[
https://issues.apache.org/jira/browse/LUCENE-8882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16876754#comment-16876754
]
Atri Sharma commented on LUCENE-8882:
-------------------------------------
My idea was not to replace IndexOrDocValues, but to allow it to be more
generally applicable.
For eg, taking the specific example of the optimized query which is applicable
for limited cases in which the index is sorted, we would ideally be better off
if we used that query over point values (even though that query is a docvalues
based implementation). However, the query is too specialized for
IndexOrDocValues to factor in.
What I was envisioning was a state where, at the start of the query,
IndexSearcher creates a QueryVisitor, sees that the index is sorted by key X,
and populates a property in the QueryVisitor's metadata (INDEX_SORTED_KEY=X).
IndexOrDocValuesQuery, then, instead of making an immediate decision as to
whether to use Points or DocValues, passes on the visitor to both of the
branches. Further down the line, the sorted index query type will see the
metadata in the visitor and volunteer itself (by adding another property in the
metadata of the visitor (SORTED_PLAN_AVAILABLE=true or something).
In the end, IndexOrDocValues will perform an evaluation, which includes the
costing which it does today + the metadata state gathered from both the
branches, and then choose the branch to execute. This will allow new query
types for specific use cases to be added easily (just add a new property type
and a listener query for it), and let the engine take better decisions as to
when to execute what queries, which can potentially lead to better query
performance.
Thoughts?
> Add State To QueryVisitor
> -------------------------
>
> Key: LUCENE-8882
> URL: https://issues.apache.org/jira/browse/LUCENE-8882
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Atri Sharma
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> QueryVisitor has no state passed in either up or down recursion. This limits
> the width of decisions that can be taken by visitation of QueryVisitor. For
> eg, for LUCENE-8881, we need a way to specify is the visitor is a rewriter
> visitor.
>
> This Jira proposes adding a property bag model to QueryVisitor, which can
> then be referred to by the Query instance being visited by QueryVisitor.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
