[ https://issues.apache.org/jira/browse/PHOENIX-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15056704#comment-15056704 ]
Hudson commented on PHOENIX-2194: --------------------------------- SUCCESS: Integrated in Phoenix-master #1022 (See [https://builds.apache.org/job/Phoenix-master/1022/]) PHOENIX-2455 Partial results for a query when PHOENIX-2194 is applied (jtaylor: rev e6ae7465ace8ccf281c175b8e44d105f5072d485) * phoenix-core/src/test/java/org/apache/phoenix/filter/SkipScanFilterTest.java * phoenix-core/src/main/java/org/apache/phoenix/filter/SkipScanFilter.java * phoenix-core/src/it/java/org/apache/phoenix/end2end/SkipScanQueryIT.java * phoenix-core/src/main/java/org/apache/phoenix/util/ScanUtil.java * phoenix-core/src/main/java/org/apache/phoenix/query/KeyRange.java > 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 > Assignee: James Taylor > Labels: AtMention, SFDC > Fix For: 4.6.0, 4.5.2 > > Attachments: PHOENIX-2194-tests.patch, PHOENIX-2194-tests2.patch, > PHOENIX-2194.patch, PHOENIX-2194_master.patch, PHOENIX-2194_master.patch, > PHOENIX-2194_v2.patch, PHOENIX-2194_v3.patch, PHOENIX-2194_v4.patch, > PHOENIX-2194_v5.patch, PHOENIX-2194_v6.patch > > > 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)