[
http://issues.apache.org/jira/browse/LUCENE-648?page=comments#action_12427630 ]
Michael McCandless commented on LUCENE-648:
---
OK I ran some basic benchmarks to test the effect on indexing of
varying the ZIP compression level from 0-9.
: > 3) A _gap_ b _gap_ c _gap_ D ...results in: A _double_gap_ D
: >
: > ...is that the behavior you are seeing?
: >
: Almost. The only difference is that case 3 has 3 gaps, so it's A
: _triple_gap_ D.
sorry ... brain fart on my part.
: 1. My bulk update code was always generating the positio
Chris Hostetter wrote on 08/11/2006 09:08 AM:
> (using lower case
> to indicate no tokens produced and upper case to indicate tokens were
> produced) ...
>
> 1) a b C _gap_ D ...results in: C _gap_ D
> 2) a B _gap_ C _gap_ D ...results in: B _gap_ C _gap_ D
> 3) A _gap_ b _gap_
: For example, if a field F has values A, B and C the following example
: cases arise:
: 1. A and B both generate no tokens ==> no positionIncrementGaps are
: generated
: 2. A has no tokens but B does ==> just the gap between B and C
: 3. A has tokens but B and C do not ==> both gaps betwe
Hi All,
There is a strange treatment of positionIncrementGap in
DocumentWriter.invertDocument().The gap is inserted between all
values of a field, except it is not inserted between values if the
prefix of the value list up to that point has not yet generated a token.
For example, if a field F
Fixed Spelling mailinglist.xml
--
Key: LUCENE-649
URL: http://issues.apache.org/jira/browse/LUCENE-649
Project: Lucene - Java
Issue Type: Improvement
Components: Website
Affects Versions: 2.0.1
If you make the compression external this is already done. In order
to do what the poster requires, you still need to read and update
fields without reading the entire document. You just do this at a
binary field level, and do all of he compression/decompression
externally.
I think puttin
I don't understand why the compressed fields are not just handled
externally in the Document class - just add uncompress/compress methods.
This way all Lucene needs to understand is binary fields, and you don't
have any of these problems during merging or initial indexing.
The original poste
I don't understand why the compressed fields are not just handled
externally in the Document class - just add uncompress/compress methods.
This way all Lucene needs to understand is binary fields, and you don't
have any of these problems during merging or initial indexing.
This is an excelle
