[
https://issues.apache.org/jira/browse/PHOENIX-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14225766#comment-14225766
]
James Taylor commented on PHOENIX-1453:
---------------------------------------
bq. Serialized along with the guidePosts as the value part of the cell. To
maintain BC we are also writing a version byte. Now the version byte is -1. Am
afraid if we can have a non zero, positive number because the first item that
we serialize here is the byteCount and that could be 0 or non zero positive
number.
How about we handle the backward compat purely through the protobuf? I don't
think we need to invent our own mechanism. An old client with a new server just
wouldn't send the row count information back (i.e. the PTableStats would end up
having a null value for row count). Probably best in the long run if we have a
protobuf specifically for PTableStats which will incrementally have more and
more information as we augment our stats.
> Collect row counts per region in stats table
> --------------------------------------------
>
> Key: PHOENIX-1453
> URL: https://issues.apache.org/jira/browse/PHOENIX-1453
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: James Taylor
> Assignee: ramkrishna.s.vasudevan
> Attachments: Phoenix-1453.patch, Phoenix-1453_1.patch,
> Phoenix-1453_2.patch
>
>
> We currently collect guideposts per equal chunk, but we should also capture
> row counts. Should we have a parallel array with the guideposts that count
> rows per guidepost, or is it enough to have a per region count?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
