[KinoSearch] the lifecycle of a Posting

[Nathan Kurz]

On 9/27/07, Marvin Humphrey <marvin at rectangular.com> wrote:
> Explaining this got me thinking.  The "bulk read" functionality is a Lucene
> artifact.  Of necessity, it's implemented differently in KS.  But I don't
> think we really need it at all.

I think that is true, and that we might even get a speed increase
processing Postings one at a time.    If we handle it immediately, it
still should be hot in L2, maybe even L1.  As it is we churn through a
lot of data at a time and then have to refetch from RAM when it's time
to use it.

Avoiding the Bulk read is also going to simplify the code and make it
possible do things more flexibly within the Posting class.

I'd like to try to get the Position code I've been working on finished
sometime soon, although I'm distracted with other projects right now.
Will you be freed up to spend some time working with me on that in a
week or two?

Nathan Kurz
nate at verse.com

_______________________________________________
KinoSearch mailing list
KinoSearch at rectangular.com
http://www.rectangular.com/mailman/listinfo/kinosearch