Hoss, This is still extremely interesting area for possible improvements; I simply don't want the topic to die http://www.nabble.com/Facet-Performance-td7746964.html
http://issues.apache.org/jira/browse/SOLR-665 http://issues.apache.org/jira/browse/SOLR-667 http://issues.apache.org/jira/browse/SOLR-669 I am currently using faceting on single-valued _tokenized_ field with huge amount of documents; _unsynchronized_ version of FIFOCache; 1.5 seconds average response time (for faceted queries only!) I think we can use additional cache for facet results (to store calculated values!); Lucene's FieldCache can be used only for non-tokenized single-valued non-bollean fields -Fuad hossman_lucene wrote: > > > : Unfortunately which strategy will be chosen is currently undocumented > : and control is a bit oblique: If the field is tokenized or multivalued > : or Boolean, the FilterQuery method will be used; otherwise the > : FieldCache method. I expect I or others will improve that shortly. > > Bear in mind, what's provide out of the box is "SimpleFacets" ... it's > designed to meet simple faceting needs ... when you start talking about > 100s or thousands of constraints per facet, you are getting outside the > scope of what it was intended to serve efficiently. > > At a certain point the only practical thing to do is write a custom > request handler that makes the best choices for your data. > > For the record: a really simple patch someone could submit would be to > make add an optional field based param indicating which type of faceting > (termenum/fieldcache) should be used to generate the list of terms and > then make SimpleFacets.getFacetFieldCounts use that and call the > apprpriate method insteado calling getTermCounts -- that way you could > force one or the other if you know it's better for your data/query. > > > > -Hoss > > > -- View this message in context: http://www.nabble.com/Facet-Performance-tp7746964p18756500.html Sent from the Solr - User mailing list archive at Nabble.com.
