On Friday, November 15, 2013 11:22 AM, Lemke, Michael SZ/HZA-ZSW wrote: Judging from numerous replies this seems to be a tough question. Nevertheless, I'd really appreciate any help as we are stuck. We'd really like to know what in our index causes the facet.method=fc query to fail.
Thanks, Michael >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 > >
