lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-2564) Integrating grouping module into Solr 4.0
Date Fri, 03 Jun 2011 21:55:47 GMT

    [ https://issues.apache.org/jira/browse/SOLR-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13044080#comment-13044080
] 

Yonik Seeley commented on SOLR-2564:
------------------------------------

I haven't been following this... I took a quick look at the patch, and at first blush it's
hard to tell what changes are cleanup and what changes are cut-over.

 - in the QueryComponent, why the change to set the GET_SCORES flag based on the sort(s)?
 - I'm not a fan of this new style for matching request parameters to enums... solr does a
*lot* of lookups on a typical request, and a switch to this style everywhere could definitely
have an impact (the whole upper-casing the request param so we can match it to the enum name).

 - "Accuracy" seems a bit mis-named?  It seems to imply an accuracy trade-off, but both methods
are 100% accurate here, they just do different things to serve different usecases.  At least
the name doesn't seem to have made it's way into the external API though.
 - The parameter "group.totalCount" I would expect to return the total count of something,
not control the pre/post faceting thing?  (or are the comments just wrong?)  If it's to return
the number of groups, then perhaps the name should be "group.groupCount" as totalCount is
unit-less.
 - What does "group.docSet" do?  The comments don't quite make sense to me, but the param
suggests it's sort of like group.totalCount?
 - I'm not sure we should default group.cache to true... there's a downside to the memory
usage, and it's fragile: things may be working just fine, and the user may add a few more
documents to the index and then the limit is hit and it just stops working (but still consumes
much memory and extra log warnings per request).
 - in the interest of reducing the number of parameters, we could dump group.cache and have
a single group.cacheMB parameter that uses 0 as no cache, -1 as maximum needed (solr uses
-1 in this manner in other places too), and other values as literal number of MB (which I'd
discourage people from using personally).


> Integrating grouping module into Solr 4.0
> -----------------------------------------
>
>                 Key: SOLR-2564
>                 URL: https://issues.apache.org/jira/browse/SOLR-2564
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Martijn van Groningen
>            Assignee: Martijn van Groningen
>             Fix For: 4.0
>
>         Attachments: LUCENE-2564.patch, SOLR-2564.patch, SOLR-2564.patch
>
>
> Since work on grouping module is going well. I think it is time to wire this up in Solr.
> Besides the current grouping features Solr provides, Solr will then also support second
pass caching and total count based on groups.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message