On 14. Jan 2007, at 3:20 , Mark Miller wrote:
Sorry Kay, I jumped in midstream...I should have read your first
post more thoroughly.
No problem, it was a bit lenghty, anyway...sorry about that. I just
tried to give enough information so that people don't get confused
too much.
By the way, many of the experts rarely comment much on the weekend
so you will probably get some good answers come Monday (lots of
replies often attract their attention <g>).
Cool :) I shouldn't be working on the weekend either, come to think
of it.
I do have one more whack though:
I don't have anything to help with the first computation...but how
about using a stale cache of the filter until the new filter is
populated? A similar idea to warming up a Searcher for field based
sorting? This would cause a slight lag, but would hide the filter
building time from the user (after the first is built of course).
Yes, I assume we will be doing all sorts of wacky stuff to hide the
computation of even the first built. Probably something along the
lines of "predictive execution". But my primary goal is to keep the
application itself as clean and simple as possible. If that means I
have to change some of the guts of Lucene, so be it.
It'd be wonderful to be able to just use our unique ids in place of
the Lucene document ids somehow - then I wouldn't even have to spent
any significant time at all constructing the filter bitsets. It
couldn't get much faster than that. We are quite obsessed with
response times, as you probably guessed by now ;) Thus my obnoxious
insistence about sharing filter caches etc.
In essence, what I want to achieve are persistent document numbers. ;)
cheers,
-k
--
Kay Röpke
http://classdump.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
