[
https://issues.apache.org/jira/browse/LUCENE-5063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13686594#comment-13686594
]
Robert Muir commented on LUCENE-5063:
-------------------------------------
i see, so we only need negatives in growablewriter for the case where we'd use
64 bpv for longs anyway.
Can we add a comment?
Also, we start at 4bpv here, but we don't bitpack for byte/short too? it could
be a little unintuitive that using long takes less ram than byte :)
Or, maybe FC should only have a 'long' API to better match DV?
{quote}
In order to not make field cache loading too slow, the GrowableWriters are
created with an acceptable overhead ratio of 50% so that they can grow the
number of bits per value quickly in order not to perform too much resizing.
{quote}
This is consistent with SortedDocValuesImpl, except SortedDocValuesImpl has a
'startBPV' of 1, whereas its 4 here. Maybe we should use 1 here too?
> Allow GrowableWriter to store negative values
> ---------------------------------------------
>
> Key: LUCENE-5063
> URL: https://issues.apache.org/jira/browse/LUCENE-5063
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Adrien Grand
> Assignee: Adrien Grand
> Priority: Trivial
> Fix For: 4.4
>
> Attachments: LUCENE-5063.patch
>
>
> For some use-cases, it would be convenient to be able to store negative
> values in a GrowableWriter, for example to use it in FieldCache: The first
> term is the minimum value and one could use a GrowableWriter to store deltas
> between this minimum value and the current value. (The need for negative
> values comes from the fact that maxValue - minValue might be larger than
> Long.MAX_VALUE.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
