[
https://issues.apache.org/jira/browse/LUCENE-7081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-7081:
--------------------------------
Attachment: LUCENE-7081.patch
initial patch after lots of experiments.
we can easily just compute how well we compress, by computing shared prefix for
the first term (count % 16 == 0) and last term (count % 16 == 15) in each
block. Thats because our terms dict here uses a single shared prefix for all
terms in a block: e.g. terms are delta encoded against the first term in the
block always.
we use prefix compression when we share at least 3 bytes per term on average:
thats because prefix encoding has some overhead vs the alternative for
fixed-width data (worst case 2 bytes per term for suffix lengths).
> Docvalues terms dict should sometimes prefix-compress fixed-length data.
> ------------------------------------------------------------------------
>
> Key: LUCENE-7081
> URL: https://issues.apache.org/jira/browse/LUCENE-7081
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Robert Muir
> Attachments: LUCENE-7081.patch
>
>
> For Sorted/SortedSet types, we encode ordinals and a term dictionary (similar
> to old lucene 3 term dictionary).
> Originally we had no prefix compression, so we "save space" in the
> fixed-width case by avoiding addressing, we can just use multiplication:
> https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/codecs/lucene54/Lucene54DocValuesConsumer.java#L423-L425
>
> But it means no compression whatsoever of the actual bytes, even if values
> are enormous, I don't think its necessarily a good tradeoff. The lack of
> prefix compression can become much more magnified now that we have fixed
> width 128-bit point types in the sandbox...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
