lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] [Commented] (SOLR-2564) Integrating grouping module into Solr 4.0
Date Wed, 08 Jun 2011 19:26:00 GMT


Michael McCandless commented on SOLR-2564:

bq. Actually, the worst case is twice as slow due to unneeded caching of a simple query.

Sorry, what do you mean here?

bq. but I still question the default, which can lead to surprisingly huge memory use (think
up to a field cache entry or more allocated per-request).

I agree; -1 is a dangerous default.

But I think caching should still default to on, just limited as a pctg
of the number of docs in the index.  Ie, by default we will cache the
result set if it's less than 20% (say) of total docs in your index.
Else we fallback to 2-pass.

I think this matches how Solr handles caching filters now?  Ie, filter
cache evicts by total filter count and not net MB right, I think?  So
that if you have more docs in your index you'll spending more RAM on
the caching...

Costly queries that return a smallish result set can see big gains
from the caching.

> Integrating grouping module into Solr 4.0
> -----------------------------------------
>                 Key: SOLR-2564
>                 URL:
>             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, SOLR-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:

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

View raw message