[
https://issues.apache.org/jira/browse/LUCENE-5721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14014703#comment-14014703
]
Yonik Seeley commented on LUCENE-5721:
--------------------------------------
This was essentially the approach I took in Heliosearch's off-heap cache, no
zigzag, and an integer average.
I don't see the point of zigzag in this specific context... if you know the
range of offsets, then you can get the extra bit back by just using an offset.
For example, -100 to 150 still maps to a single byte: 0-256 with an offset of
-100.
> Monotonic packed could maybe be faster
> --------------------------------------
>
> Key: LUCENE-5721
> URL: https://issues.apache.org/jira/browse/LUCENE-5721
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Robert Muir
> Assignee: Adrien Grand
>
> This compression is used in lucene for monotonically increasing offsets, e.g.
> stored fields index, dv BINARY/SORTED_SET offsets, OrdinalMap (used for
> merging and faceting dv) and so on.
> Today this stores a +/- deviation from an expected line of y=mx + b, where b
> is the minValue for the block and m is the average delta from the previous
> value. Because it can be negative, we have to do some additional work to
> zigzag-decode.
> Can we just instead waste a bit for every value explicitly (lower the
> minValue by the min delta) so that deltas are always positive and we can have
> a simpler decode? Maybe If we do this, the new guy should assert that values
> are actually monotic at write-time. The current one supports "mostly monotic"
> but do we really need that flexibility anywhere? If so it could always be
> kept...
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
