[
https://issues.apache.org/jira/browse/SOLR-18309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18097173#comment-18097173
]
Jason Gerlowski commented on SOLR-18309:
----------------------------------------
I couldn't find any past discussion of this, but figured it was worth asking.
Have you guys discussed or thought about this particular query-limit gap in the
past [~gus] [~ab]? Any suggestions for where we could look to close this gap?
Joins in particular are both common and expensive, I'd love to figure out a way
to make their more expensive bits subject to timeAllowed and other limits.
> Query limits should apply to expensive-to-create scorers
> --------------------------------------------------------
>
> Key: SOLR-18309
> URL: https://issues.apache.org/jira/browse/SOLR-18309
> Project: Solr
> Issue Type: Improvement
> Components: Query Limits
> Affects Versions: main(11.0)
> Reporter: Jason Gerlowski
> Priority: Major
>
> Solr's timeAllowed enforcement relies on wrapping the BulkScorer returned by
> Weight.bulkScorer()/scorer() in Lucene's TimeLimitingBulkScorer. This
> wrapping class checks the deadline periodically while documents are actually
> being scored and collected.
> This is sufficient in most cases. But it leaves a gap: short-circuiting can
> only be done after the scorer has been created. This is a problem for
> queries such as "join" or "graph", where scorer-creation itself involves a
> ton of work, issuing sub-requests, etc. None of this scorer-creation work is
> subject to timeAllowed and as a result (e.g.) join queries regularly run
> waaaay over their timeAllowed or other query limits.
> We should find a way to make scorer-creation itself subject to query limits,
> if possible. Or alternatively, rework these query implementations so that
> scorer-creation is a cheaper operation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
