[
https://issues.apache.org/jira/browse/SOLR-9501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15482357#comment-15482357
]
David Smiley commented on SOLR-9501:
------------------------------------
I don't think a marker interface is the right design. It's only possible for a
PostFilter to use the score (right?), and so perhaps a method should be added
to PostFilter. PostFilter has one method getFilterCollector(IndexSearcher) to
return a Collector. Lucene Collector.needsScores() exists so perhaps we need
nothing new after all? Although getting the collector is not necessarily
trivial only to throw away the result just to see what needsScores() returns.
Perhaps the related SolrIndexSearcher logic to support this should actually be
in processFilter()? getDocSet would then need to work with a Scorer somehow...
(even if sometimes it's a dummy one) so it can call setScorer on each segment
when it collects.
Related to this, CollapsingPostFilter.getCache() is hard-coded to return false.
Perhaps a non-cacheable query
Any way, I'm punting on this for now.
> Collapse filter should sometimes be cacheable instead of never
> --------------------------------------------------------------
>
> Key: SOLR-9501
> URL: https://issues.apache.org/jira/browse/SOLR-9501
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: David Smiley
>
> When SolrIndexSearcher.getDocSet(List<Query>queries) is called, it first
> checks if any implement the marker interface ScoreFilter, and if so it calls
> out to getDocSetScore\[1] instead of continuing. CollapsingPostFilter is the
> only Query implementing ScoreFilter. There is a presumption here that any
> CollapsingPostFilter needs the score. But this just isn't true; you can
> collapse with a min/max/sort on something that doesn't need the score. So
> there is a needless performance hit here.
> \[1] I don't like that getDocSetScore presumes the first query in the list
> is the scoring one -- it's a poor API contract relationship; at a minimum the
> javadocs should be updated. This holds for getDocSet as well since it passes
> through. Perhaps getDocSet could be modified to take a nullable scoring Query
> first arg.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
