[
https://issues.apache.org/jira/browse/SOLR-6143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020051#comment-14020051
]
Joel Bernstein commented on SOLR-6143:
--------------------------------------
Let's move this discussion to the users list. I'll provide my answer here and
close out the ticket unless a bug comes up during the discussion on the list.
I'll repost this to users list also.
The CollapsingQParserPlugin should give you the same facet counts as
group.truncate.
You're using group.facets, which the CollapsingQParserplugin doesn't yet
support. I think this would be an excellent feature, so we could make a jira
ticket to add this feature.
> Bad facet counts from CollapsingQParserPlugin
> ----------------------------------------------
>
> Key: SOLR-6143
> URL: https://issues.apache.org/jira/browse/SOLR-6143
> Project: Solr
> Issue Type: Bug
> Components: query parsers
> Affects Versions: 4.8.1
> Environment: UNIX
> Tomcat 7.0.33
> SOLR 4.8.1
> 16 GB RAM
> Reporter: David Fennessey
>
> I'm noticing a very weird bug using the CollapsingQParserPlugin. We tried to
> use this plugin when we realized that faceting on the groups would take a
> ridiculous amount of time. To its credit, it works very quickly, however the
> facet counts that it gives are incorrect.
> We have a smallish index of about 200k documents with about with about 50k
> distinct groups within it.
> When we use the group implementation
> (&group=true&group.field=PrSKU&group.facet=true) which I believe this
> attempts to emulate, the facet counts are totally correct.
> When we use the field collapsing implementation, it will show an incorrect
> count for the non-filtered query, but when we go to the filtered query, the
> facet count corrects itself and matches the document count.
> Here are some SOLR responses:
> solrslave01:8983/index/select?q=classIDs:12&fl=PrSKU&fq={!collapse%20field=PrSKU}&facet=true&facet.field=at_12_wood_tone
> The facet field will return
> <int name="Dark Wood">867</int>
> <int name="Medium Wood">441</int>
> <int name="Light Wood">253</int>
> When I actually apply a filter query like so:
> solrslave01:8983/index/select?q=classIDs:12&fl=PrSKU&fq={!collapse%20field=PrSKU}&facet=true&facet.field=at_12_wood_tone&fq=at_12_wood_tone:%22Light%20Wood%22
> I actually pull back 270 results and the facet updates itself with the
> correct number at the bottom
> <int name="Light Wood">270</int>
> <int name="Dark Wood">68</int>
> <int name="Medium Wood">66</int>
> If this were the same number pre and post filter query I would assume that it
> was simply my data that was bad, however I've pored over this for the better
> part of a day and I'm pretty sure it's the plugin. For reference, this field
> that I'm faceting on is a multiValued field, however I have noticed the exact
> same behavior on non multiValued fields (such as price).
> I can provide any other details you might need
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
