[
https://issues.apache.org/jira/browse/SOLR-2963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13553927#comment-13553927
]
James Dyer commented on SOLR-2963:
----------------------------------
FYI- your workaround is similar to the approach on SOLR-2242. In this case, it
counts the unique facet values internally and just returns you the count so you
do not need to send all that data over the wire to your application.
Are you finding that using faceting for the total # of groups performs better
than "nGroups"? I was under the impression that "nGroups" was designed to
perform better than the faceting workaround and in fact am in the process of
converting an application to use "nGroups" from the current SOLR-2242-based
implementation. I'm assuming though that "nGroups" will scale better, but your
comment here makes me wonder if it indeed is worse?
> Improving the performance of group.ngroups=true when there are a lot of
> unique groups
> -------------------------------------------------------------------------------------
>
> Key: SOLR-2963
> URL: https://issues.apache.org/jira/browse/SOLR-2963
> Project: Solr
> Issue Type: Improvement
> Components: SearchComponents - other
> Affects Versions: 3.5
> Environment: Linux (Debian 6) 64bit, Java 6, 21GB RAM (Xmx), Solr 3.5
> Reporter: Michael Jakl
>
> The performance of computing the total number of groups (by setting
> group.ngroups=true) degrades badly when there are many unique groups.
> It would be very useful to have an adequate number of groups to provide good
> means for paging through the results etc.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]