[ 
https://issues.apache.org/jira/browse/PHOENIX-4845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16655889#comment-16655889
 ] 

Daniel Wong commented on PHOENIX-4845:
--------------------------------------

Some other issues with trying to handle behavior for paging using modified 
comparisons is that if Phoenix ever tries to do cost based optimizations and 
you are uncertain if the index or the base table is going to be used as the 
sort order for a partial key.  SQL in general is not really built to handle the 
users knowing the underlying structure of the data so custom language features 
often become the approach.  I do agree in principal though with [~jamestaylor] 
that avoiding non-sql standard behavior and language should be avoided. 
 One of the reasons I prefer paging approaches like server side cursors similar 
to https://issues.apache.org/jira/browse/PHOENIX-2606.  

[~tdsilva] I did minor testing on invert and Lars did some of my phoenix-4841 
patch which causes it to essentially ignore the invert.  When I have some more 
time I will see what it does prior to my changes on initial investigation I did 
attempt to use inverts and it was not handling all the cases to sql standard.

> Support using Row Value Constructors in OFFSET clause to support paging in 
> tables where the sort order of PK columns varies
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: PHOENIX-4845
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-4845
>             Project: Phoenix
>          Issue Type: New Feature
>            Reporter: Thomas D'Silva
>            Priority: Major
>              Labels: DESC, SFDC
>         Attachments: PHOENIX-offset.txt
>
>
> RVCs along with the LIMIT clause are useful for efficiently paging through 
> rows (see [http://phoenix.apache.org/paged.html]). This works well if the pk 
> columns are sorted ascending, we can always use the > operator to query for 
> the next batch of row. 
> However if the PK of a table is (A  DESC, B DESC) we cannot use the following 
> query to page through the data
> {code:java}
> SELECT * FROM TABLE WHERE (A, B) > (?, ?) ORDER BY A DESC, B DESC LIMIT 20
> {code}
> Since the rows are sorted by A desc and then by B descending we need change 
> the comparison order
> {code:java}
> SELECT * FROM TABLE WHERE (A, B) < (?, ?) ORDER BY A DESC, B DESC LIMIT 20
> {code}
> If the PK of a table contains columns with mixed sort order for eg (A  DESC, 
> B) then we cannot use RVC to page through data. 
> If we supported using RVCs in the offset clause we could use the offset to 
> set the start row of the scan. Clients would not have to have logic to 
> determine the comparison operator. This would also support paging through 
> data for tables where the PK columns are sorted in mixed order. 
> {code:java}
> SELECT * FROM TABLE ORDER BY A DESC, B LIMIT 20 OFFSET (?,?)
> {code}
> We would only allow using the offset if the rows are ordered by the sort 
> order of the PK columns.
>  
> FYI [~jfernando_sfdc]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to