lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (JIRA)" <>
Subject [jira] [Commented] (SOLR-9501) Collapse filter should sometimes be cacheable instead of never
Date Sun, 11 Sep 2016 21:37:20 GMT


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:
>             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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message