[
https://issues.apache.org/jira/browse/PHOENIX-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14708143#comment-14708143
]
James Taylor commented on PHOENIX-2194:
---------------------------------------
[~maryannxue] - just curious - does our Calcite-based Phoenix handles this
already?
> order by should not require all PK fields with = constraint
> -----------------------------------------------------------
>
> Key: PHOENIX-2194
> URL: https://issues.apache.org/jira/browse/PHOENIX-2194
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.5.0
> Environment: linux
> Reporter: Gary Horen
> Labels: AtMention, SFDC
>
> Here is a table:
> CREATE TABLE IF NOT EXISTS FEEDS.STUFF
> (
> STUFF CHAR(15) NOT NULL,
> NONSENSE CHAR(15) NOT NULL
> CONSTRAINT PK PRIMARY KEY
> (
> STUFF,
> NONSENSE
>
> )
> ) VERSIONS=1,MULTI_TENANT=TRUE,REPLICATION_SCOPE=1
> Here is a query:
> explain SELECT * FROM feeds.stuff
> where stuff = ' '
> and nonsense > ' '
> order by nonsense
> Here is the plan:
> CLIENT 1-CHUNK PARALLEL 1-WAY RANGE SCAN
> SERVER FILTER BY FIRST KEY ONLY
> SERVER TOP 100 ROWS SORTED BY [NONSE
> CLIENT MERGE SORT
> If I change to ORDER BY STUFF, NONSENSE I get:
> CLIENT 1-CHUNK SERIAL 1-WAY RANGE SCAN O
> SERVER FILTER BY FIRST KEY ONLY AND
> SERVER 100 ROW LIMIT
> CLIENT 100 ROW LIMIT
> Since the leading constraint is =, ORDER BY will be unaffected by it, so
> ORDER BY should not need the leading constraint; it should only require the
> columns whose values would vary (which, since they are ordered by the key,
> should (and do) result in the client side sort being optimized out.) Having
> to include the leading = constraints in the ORDER BY clause is very
> counter-intuitive.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
