[
https://issues.apache.org/jira/browse/PHOENIX-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16650674#comment-16650674
]
Lars Hofhansl commented on PHOENIX-172:
---------------------------------------
The sort order of RVC has to be consistent with the PKs natural sort order. It
specifically does *not* translate comparing each column.
(a,b) < (x,y) is true exactly when the pk (a,b) sorts before pk (x,y).
In your example above (b,1) > (b, 2) based on the key's sort order. That's how
RVC should behave. And it's what they do in fact, right?
> Support the ability for a client to do query more
> -------------------------------------------------
>
> Key: PHOENIX-172
> URL: https://issues.apache.org/jira/browse/PHOENIX-172
> Project: Phoenix
> Issue Type: Task
> Affects Versions: 2.1.0
> Reporter: James Taylor
> Assignee: Samarth Jain
> Labels: enhancement
>
> Clients often need the ability to "page" through query results that have more
> row results than are displayable on a single screen. SQL provides LIMIT and
> OFFSET which is often used for this purpose, however supporting OFFSET in a
> performant manner is not possible with HBase. Instead, an alternate way of
> supporting query-more functionality (suggested by @larsh) is through [row
> values
> constructors](http://publib.boulder.ibm.com/infocenter/soliddb/v6r3/index.jsp?topic=/com.ibm.swg.im.soliddb.sql.doc/doc/row.value.constructors.html)
> which has been in the SQL spec since SQL-92. It has PostGres support as
> well with the benefits explained well
> [here](https://wiki.postgresql.org/images/3/35/Pagination_Done_the_PostgreSQL_Way.pdf)
> .
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
