RLE Compressing bit vectors, just toughts

2007-08-04 Thread eks dev
Would it be possible somehow to make skip list (postings) RLE compressed without affecting performance in cases where RLE cannot identify longer runs? we have an unusual (?) case where we have an opportunity to sort documents on category field before indexing. this order gets slightly disturbed

[jira] Updated: (LUCENE-550) InstantiatedIndex - faster but memory consuming index

2007-08-04 Thread Karl Wettin (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wettin updated LUCENE-550: --- Attachment: LUCENE-550_20070804_no_core_changes.txt This is a small and completely isolated version o

Re: RLE Compressing bit vectors, just toughts

2007-08-04 Thread Paul Elschot
On Saturday 04 August 2007 09:36, eks dev wrote: > Would it be possible somehow to make skip list (postings) RLE compressed without affecting performance in cases where RLE cannot identify longer runs? I suppose you mean run length encoding? (I missed the first posting about this.) > > we have

Re: RLE Compressing bit vectors, just toughts

2007-08-04 Thread eks dev
Hi Paul, thanks for feedback >I suppose you mean run length encoding? (I missed the first posting about this.) You are right, that is what I meant by RLE. This was the first posting. I am just trying get some feedback to see if there are some knock-out conditions disqualifying this idea. a b

Re: RLE Compressing bit vectors, just toughts

2007-08-04 Thread Paul Elschot
Eks, Two things: In the latest Matcher patches I forgot to consider your implementation of a Matcher on OpenBitSet. In case I don't mention this there, please holler there when things start moving. My implementation of that in the latest patches is really no more than a first attempt, and mostly