: Thanks for your kind reply. The problem is solved with sharding and using : facet.method=enum. I am curious about what's the different between enum : and fc, so that enum works but fc does not. Do you know something about : this?
method=fc/fcs uses the field caches (or uninverted fields if they are multivalued) to build a large data structure that is reusable across many requests and allows faceting happen very quickly even when the number of terms is large. enum causes solr to walk the term enum for the field and generate a DocSet for each term which is then intersected with the main results -- basically doing "facet.field" just like "facet.query" iwth simple term queries. these DocSets from using facet.method=enum will be cached in the filterCache, so there is some performance savings there if/when people filter on these facet constraints, but the regular rules about cache evicitions apply. So in a situation where the heap size is "big enough not to matter" method=fc should be faster and take up less ram then if you size your filterCache big enough to hold all of the DocSets involved if you use method=enum to not have cache evictions. In most cases, the only motivation for using method=enum is if you know the cardinality of your set of constraints is relatively small and fixed (ie: there are only 50 states in the US, so you might find that faceting on a "state" field with method=enum is just as fast as using method=fc and takes less ram -- this is why boolean fields default to method=enum, the cardinality is garunteed to be "2"). But in some less common cases, you might care more about saving ram then speed, or you might be trying to facet on huge index with fields containing lots of terms (ie: full text) so that method=fc just wont work with any concievable amount of ram, so it could make sense to use method=enum with filterCache disabled. -Hoss
