[
https://issues.apache.org/jira/browse/SOLR-9501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15482441#comment-15482441
]
David Smiley commented on SOLR-9501:
------------------------------------
What I said RE getCached might make no sense; PF's like this are supposed to
return false since they can't really be cacheable by themselves.
Also related, I have a suspicion the needsScores boolean inside
CollapsingPostFilter may be less than ideal, as it conflates two things: wether
the Filter actually needs the scores itself to do its collapsing job, or wether
some follow-on Collector (if any) needs scores. In both cases it needs to get
the scores, but if it's only the latter case then the overall needsScores()
determination can wait until the time of execution when the delegate collector
is in place, which can be interrogated with needsScores(). With that, I
suspect some improvements could be made to avoid the brittle-looking logic in
CPF's constructor that looks at the overall request to see if scores are needed
in parts that aren't related to the CPF itself. e.g. if the user sorting by
score, then the delegate collector is going to have needsScores() return true
(I think?) so it needn't find ways to detect all the possible circumstances in
which a score might be used.
> 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]
