> Better would be a stacked approach, where the orig full array remains > and we write sparse deltas (pairs of docID + new value), and at init > we load the base and apply all the diffs (in order). Merging would > periodically coalesce them down again...
I think this approach would be great for the DF in RT. It's better than a multidimensional array? As the lookup cost won't be too high, and we can instantiate a new main int[] every N. I'll enumerate the options we've gone over in the LUCENE-2312 issue, so we don't forget! On Mon, Jan 17, 2011 at 3:24 AM, Michael McCandless <[email protected]> wrote: > On Sun, Jan 16, 2011 at 11:35 AM, Jason Rutherglen > <[email protected]> wrote: >>> But: they don't yet support updating the values (the goal is to allow >>> this, eventually). This is just the first step. >> >> No? Hmm... I thought that was a main part of the functionality? > > Patches welcome ;) > > Seriously, how would you do it? IE, I don't like how norms handle it > today -- on changing a single value we must write the full array (for > all docs). Same problem w/ del docs, though since its 1 bit per doc > the cost is far less. > > Better would be a stacked approach, where the orig full array remains > and we write sparse deltas (pairs of docID + new value), and at init > we load the base and apply all the diffs (in order). Merging would > periodically coalesce them down again... > > Mike > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
