[
https://issues.apache.org/jira/browse/PHOENIX-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15802455#comment-15802455
]
James Taylor commented on PHOENIX-2565:
---------------------------------------
[~enis] - for a null value, we store an offset, but no data. There's a slight
hack to differentiate setting something to null versus the value being absent
(based on the offset being positive or negative). We need to be able to
differentiate these two based on our default column value implementation.
There's no cost for trailing null values.
Using a bit set would still be close to O(1) as using Long.bitCount() would
check 64 bits worth pretty quickly, but there'd be some overhead. Not sure if
it's worth doing this right now or not - we could always add it later as a new
storage format - it'd basically cut the storage cost of the offsets by 1/8. The
data value bytes would remain the same.
IMHO, I think PHOENIX-3570 is higher priority.
> Store data for immutable tables in single KeyValue
> --------------------------------------------------
>
> Key: PHOENIX-2565
> URL: https://issues.apache.org/jira/browse/PHOENIX-2565
> Project: Phoenix
> Issue Type: Improvement
> Reporter: James Taylor
> Assignee: Thomas D'Silva
> Attachments: PHOENIX-2565-v2.patch, PHOENIX-2565-wip.patch,
> PHOENIX-2565.patch
>
>
> Since an immutable table (i.e. declared with IMMUTABLE_ROWS=true) will never
> update a column value, it'd be more efficient to store all column values for
> a row in a single KeyValue. We could use the existing format we have for
> variable length arrays.
> For backward compatibility, we'd need to support the current mechanism. Also,
> you'd no longer be allowed to transition an existing table to/from being
> immutable. I think the best approach would be to introduce a new IMMUTABLE
> keyword and use it like this:
> {code}
> CREATE IMMUTABLE TABLE ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
