bq: There will be no updates to my index. So, no worries about ageing out or garbage collection
This is irrelevant to aging out filterCache entries, this is purely query time. bq: Each having 64 GB of RAM, out of which I am allocating 45 GB to Solr. It's usually a mistake to give Solr so much ram relative to the OS, see Uwe's excellent blog here: http://blog.thetaphi.de/2012/07/use-lucenes-mmapdirectory-on-64bit.html That said, you know your system best. And the fact that you have so many shards may well mean that memory considerations aren't relevant. Personally, though, I think you've massively over-sharded your collection and are incurring significant overhead, but again you know your requirements much better than I do. Best, Erick On Mon, Dec 29, 2014 at 7:43 AM, Yonik Seeley <yo...@heliosearch.com> wrote: > On Fri, Dec 26, 2014 at 12:26 PM, Erick Erickson > <erickerick...@gmail.com> wrote: >> I don't know the complete algorithm, but if the number of docs that >> satisfy the fq is "small enough", >> then just the internal Lucene doc IDs are stored rather than a bitset. > > If smaller than maxDoc/64 ids are collected, a sorted int set is used > instead of a bitset. > Also, the enum method can skip caching for the "smaller" terms: > > facet.enum.cache.minDf=100 > might be good for general purpose. > Or set the value really high to not use the filter cache at all. > > -Yonik
