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]

Reply via email to