Another followup: I bumped all the caches in solrconfig.xml to
size="1600384"
initialSize="400096"
autowarmCount="400096"
It seemed to fix the problem on a very small index (facets on last and
first author fields, + 12 range date facets, sub 0.3 seconds for
queries). I'll check on the full index tomorrow (it's indexing right
now, 400docs/sec!). However, I still don't have an idea what are these
values representing, and how I should estimate what values I should set
them to. Originally I thought it was the size of the cache in kb, and
someone on the list told me it was number of items, but I don't quite
get it. Better documentation on that would be welcomed :)
Also, is there any plans to add an option not to run a facet search if
the result set is too big? To avoid 40 seconds queries if the docset is
too large...
Thanks,
Michael Imbeault
CHUL Research Center (CHUQ)
2705 boul. Laurier
Ste-Foy, QC, Canada, G1V 4G2
Tel: (418) 654-2705, Fax: (418) 654-2212
Yonik Seeley wrote:
On 9/18/06, Michael Imbeault <[EMAIL PROTECTED]> wrote:
Just a little follow-up - I did a little more testing, and the query
takes 20 seconds no matter what - If there's one document in the results
set, or if I do a query that returns all 130000 documents.
Yes, currently the same strategy is always used.
intersection_count(docs_matching_query, docs_matching_author1)
intersection_count(docs_matching_query, docs_matching_author2)
intersection_count(docs_matching_query, docs_matching_author3)
etc...
Normally, the docsets will be cached, but since the number of authors
is greater than the size of the filtercache, the effective cache hit
rate will be 0%
-Yonik
