Bill Bell <billnb...@gmail.com> wrote: > The limit is set to -1. But the average result is 300.
Okay, better. Well, somewhat better. But unless your values are very well distributed, I would guess that your worst case is very high. Have you checked if your performance problems are for specific queries? One way is to look through your solr.log for high QTimes and see if that correlates with large result sets. My guess (still assuming distributed search) is that lines containing __terms (indicating the fine count phase of distributed faceting) will have higher QTimes that the other queries. > Would creating 900 fields be better ? > Then I could just put the prefix in the field name. With fc, there is an constant overhead for each field that you facet on. 900 fields would take up much more memory than a single field with all the values. I don't think that enum leaves structures in memory, but I doubt that it would be better than using a single field and facet.prefix. > So far I heard solcloud, docvalues as viable solutions. Stay away from enum. SolrCloud is not a solution to faceting as such. There is a performance penalty when switching from single-shard to SolrCloud, especially for the fairly large facet result sets that you have. I just guessed that you were using SolrCloud already. A quick test: Try setting facet.limit=10 and run some tests. If performance is fine for that and you're using multiple shards, then your performance (at least for faceting) would probably be a lot higher with just a single shard. - Toke Eskildsen