[
https://issues.apache.org/jira/browse/SOLR-9786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15685734#comment-15685734
]
Yonik Seeley commented on SOLR-9786:
------------------------------------
{quote}
> This is no longer desirable
That wording suggests to me there was some change to something that made the
current code inefficient... but my understanding here is instead this is really
just an optimization that could have actually been added a long time ago
{quote}
I was speaking from the perspective of when the QueryParser was first
created... there was no reason to not just immediately create a query for each
clause. Compared to now, when we have query types that can do set queries more
efficiently.
bq. SOLR-2883 What do you think of the local-params approach suggested there?
If we needed a local param for it, that could set the right flag. But I'm not
sure it is needed? filter queries should always ignore scores, and in a
relevance query, one can always use something like filter(). Ultimately I
think this should be an input to the qparser constructor... but that can
probably wait for some refactoring when JSON query parsing comes along in an
integrated form with QParsers.
> Defer creation of clauses in parser, optionally delegate groups to
> FieldType.getSetQuery
> ----------------------------------------------------------------------------------------
>
> Key: SOLR-9786
> URL: https://issues.apache.org/jira/browse/SOLR-9786
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Yonik Seeley
> Assignee: Yonik Seeley
> Attachments: SOLR-9786.patch
>
>
> Solr's query parser currently creates a query for each clause it sees
> independently. This is no longer desirable, since if we are creating a
> filter (non-scoring query), we can use a TermsQuery.
> PointFields SOLR-8396 also need to see a set of values together to
> efficiently create a set query.
> This issue:
> - adds context for the parser to know when it's parsing a query for matching
> only (that's only for the TermsQuery... I assume Points would always use a
> set query when passed multiple values)
> - defers creation of real Query objects for simple term queries in a boolean
> query
> - aggregates those values by field at the end to be passed to a new
> FieldType.getSetQuery method
> - FieldType.getSetQuery base implementation uses TermsQuery for indexed
> fields
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
