[
https://issues.apache.org/jira/browse/SOLR-8879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18132067#comment-18132067
]
Nick Shanin commented on SOLR-8879:
-----------------------------------
>From code reading against apache/main b73f03976fa, when the grouping cache
>overflows, the second pass runs without the PostFilter wrapper
>(solr/core/src/java/org/apache/solr/search/Grouping.java:386-391), while the
>non-overflow branch wraps it (Grouping.java:394-398). A non-cached post filter
>can then be ignored on the overflow path. Is this still reproduced?
🤖 AI-generated 🤖
> Wrong number of matches is returned when group cache limit is exceeded and
> some results are filtered by a post filter
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-8879
> URL: https://issues.apache.org/jira/browse/SOLR-8879
> Project: Solr
> Issue Type: Bug
> Components: search
> Affects Versions: 5.3.1
> Reporter: Erez Michalak
> Priority: Major
>
> When the group cache limit is exceeded (see the warning "The grouping cache
> is active, but not used because it exceeded the max cache limit of %d
> percent" at the Grouping class), and some of the results are filtered by a
> post filter, the number of matches at the response is wrong (doesn't take the
> post filter into account).
> Seems like this can be fixed if the following lines are added after the
> warning and before searchWithTimeLimiter:
> if (pf.postFilter != null) {
> pf.postFilter.setLastDelegate(secondPhaseCollectors);
> secondPhaseCollectors = pf.postFilter;
> }
> (because exceeding the cache limit should work exactly as working with no
> cache at all)
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
