On 6/10/06, zzzzz shalev <[EMAIL PROTECTED]> wrote:
"the number of facets to check per request
average somewhere between 100 and 200 (the total number of unique
facets is much larger though). "
you mean 100 - 200 different catagories to facet?
I was going by memory, but 100 to 200 set intersections (specific
counts to gather) per individual request.
i ran the test on a 600,000 doc index, however the cool thing about my
solution, is that the total doc count is not too relavant
Yeah, you can always get faster if aproximations are OK.
i do this so that the facet counts i display are from good docs, i am trying
to avoid a situation where i recieve 5,000 results and that 4,500 of them with
awful rankings have the same facet values and therefore the facets displayed in
the UI are of bad ranked docs
confusing!!!!
Actually, that sounds like it can make a lot of sense, as long as you
can approximate what is good vs bad.
however , i will look into your impl, it sounds solid, i am curretly on
lucene 1.4.3 (which classes should i look into in solr?)
Solr doesn't do faceted browsing for you yet. It provides caching of
sets and fast set intersections. You currently need code to tell solr
what intersection counts to get.
DocSetHitCollector and HashDocSet + BitDocSet would only help you if
you cache sets of docids.
-Yonik
http://incubator.apache.org/solr Solr, the open-source Lucene search server
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
