On Thu, November 14, 2013 7:26 PM, Yonik Seeley wrote: >On Thu, Nov 14, 2013 at 12:03 PM, Lemke, Michael SZ/HZA-ZSW ><lemke...@schaeffler.com> wrote: >> I am running into performance problems with faceted queries. >> If I do a >> >> q=word&facet.field=CONTENT&facet=true&facet.limit=10&facet.mincount=1&facet.method=fc&facet.prefix=a&rows=0 >> >> I am getting an exception: >> org.apache.solr.common.SolrException: Too many values for UnInvertedField >> faceting on field CONTENT >> at >> org.apache.solr.request.UnInvertedField.uninvert(UnInvertedField.java:384) >> at >> org.apache.solr.request.UnInvertedField.<init>(UnInvertedField.java:178) >> at >> org.apache.solr.request.UnInvertedField.getUnInvertedField(UnInvertedField.java:839) >> ... >> >> I understand it's got something to do with a 24bit limit somewhere >> in the code but I don't understand enough of it to be able to construct >> a specialized index that can be queried with facet.method=enum. > >You shouldn't need to do anything differently to try facet.method=enum >(just replace facet.method=fc with facet.method=enum)
This is true and facet.method=enum does work indeed. The problem is runtime. In particular queries with an empty facet.prefix= run many seconds if not minutes. I initially asked about this here: http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201310.mbox/%3c33ec3398272fbe47b64ee3b3e98f69a761427...@de011521.schaeffler.com%3E It was suggested that fc is much faster than enum and I'd like to test that. We are still fairly free to design the index such that it performs well. But to do that we need to understand what is killing it. > >You may also want to add the parameter >facet.enum.cache.minDf=100000 >to lower memory usage by only usiing the filter cache for terms that >match more than 100K docs. That helped a little, cut down my particular test from 10 sec to 5 sec. But still too slow. Mind you this is for an autosuggest feature. Thanks for your reply. Michael
