[jira] [Updated] (PHOENIX-7352) Improve OrderPreservingTracker to support extracting partial ordering columns for TupleProjectionPlan

[chenglei (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenglei updated PHOENIX-7352:
--
Description: 
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the inner query of the second sql, we infer the output 
{{OrderBy}} from "select v1, v2, pk3" based on "order by t.v2, t.pk3". This 
work is done by {{OrderPreservingTracker}} in {{TupleProjectionPlan}} . But for 
{{OrderPreservingTracker}}, it could not support extracting partial ordering 
columns, when it finds that {{v1}} in "select v1, v2, pk3" does not appear in 
"order by t.v2, t.pk3",   {{OrderPreservingTracker.isOrderPreserving}} returns 
false, and 
{{OrderPreservingTracker.getOrderPreservingTrackInfos}} returns an empty list 
in {{TupleProjectionPlan}}. 

We should modify {{OrderPreservingTracker}} to make 
{{OrderPreservingTracker.getOrderPreservingTrackInfos}} could also extract 
partial continuous ordering columns which start from the first column even if 
{{OrderPreservingTracker.isOrderPreserving}} is false.  That is to say, even if 
{{v1}} in "select v1, v2, pk3" does not appear in "order by t.v2, t.pk3", it 
will return the partial ordered "v2, pk3".

  was:
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the inner query of the second sql, we infer the output 
{{OrderBy}} from "select v1, v2, pk3" based on "order by t.v2, t.pk3". This 
work is done by {{OrderPreservingTracker}} in {{TupleProjectionPlan}} . But for 
{{OrderPreservingTracker}}, it could not support extracting partial ordering 
columns, when it finds that {{v1}} in "select v1, v2, pk3" does not appear in 
"order by t.v2, t.pk3",   {{OrderPreservingTracker.isOrderPreserving}} returns 
false, and 
{{OrderPreservingTracker.getOrderPreservingTrackInfos}} returns an empty list 
in {{TupleProjectionPlan}}. 

We should modify {{OrderPreservingTracker}} to make 
{{OrderPreservingTracker.getOrderPreservingTrackInfos}} could also extract 
partial continuous ordering columns which start from the first column even if 
{{OrderPreservingTracker.isOrderPreserving}} is false.  That is to say, even if 
{{v1}} in "select v1, v2, pk3" does not appear in "order by t.v2, t.pk3", it 
will return the partial ordered "v2,pk3".


> Improve OrderPreservingTracker to support extracting partial ordering columns 
> for TupleProjectionPlan 
> --
>
> Key: PHOENIX-7352
> URL: https://issues.apache.org/jira/browse/PHOENIX-7352
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.2.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Major
>
> This is an improvement for  

[jira] [Updated] (PHOENIX-7352) Improve OrderPreservingTracker to support extracting partial ordering columns for TupleProjectionPlan

[chenglei (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenglei updated PHOENIX-7352:
--
Description: 
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the inner query of the second sql, we infer the output 
{{OrderBy}} from "select v1, v2, pk3" based on "order by t.v2, t.pk3". This 
work is done by {{OrderPreservingTracker}} in {{TupleProjectionPlan}} . But for 
{{OrderPreservingTracker}}, it could not support extracting partial ordering 
columns, when it finds that {{v1}} in "select v1, v2, pk3" does not appear in 
"order by t.v2, t.pk3",   {{OrderPreservingTracker.isOrderPreserving}} returns 
false, and 
{{OrderPreservingTracker.getOrderPreservingTrackInfos}} returns an empty list 
in {{TupleProjectionPlan}}. 

We should modify {{OrderPreservingTracker}} to make 
{{OrderPreservingTracker.getOrderPreservingTrackInfos}} could also extract 
partial continuous ordering columns which start from the first column even if 
{{OrderPreservingTracker.isOrderPreserving}} is false.  That is to say, even if 
{{v1}} in "select v1, v2, pk3" does not appear in "order by t.v2, t.pk3", it 
will return the partial ordered "v2,pk3".

  was:
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the inner query of the second sql, we infer the output 
{{OrderBy}} from "select v1, v2, pk3" based on "order by t.v2, t.pk3". This 
work is done by {{OrderPreservingTracker}} in {{TupleProjectionPlan}} . But for 
{{OrderPreservingTracker}}, it could not support extracting partial ordering 
columns, when it finds that {{v1}} in "select v1, v2, pk3" does not appear in 
"order by t.v2, t.pk3",   {{OrderPreservingTracker.isOrderPreserving}} returns 
false, and 
{{OrderPreservingTracker.getOrderPreservingTrackInfos}} returns an empty list 
in {{TupleProjectionPlan}}. 

We should modify {{OrderPreservingTracker}} to make 
{{OrderPreservingTracker.getOrderPreservingTrackInfos}} could also extract 
partial continuous ordering columns which start from the first column even if 
{{OrderPreservingTracker.isOrderPreserving}} is false.  That is to say, even if 
{{v1}} in "select v1, v2, pk3" does not appear in "order by t.v2, t.pk3", it 
will return the ordered {{v2,pk3}}.


> Improve OrderPreservingTracker to support extracting partial ordering columns 
> for TupleProjectionPlan 
> --
>
> Key: PHOENIX-7352
> URL: https://issues.apache.org/jira/browse/PHOENIX-7352
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.2.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Major
>
> This is an improvement for  

[jira] [Updated] (PHOENIX-7352) Improve OrderPreservingTracker to support extracting partial ordering columns for TupleProjectionPlan

[chenglei (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenglei updated PHOENIX-7352:
--
Description: 
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the inner query of the second sql, we infer the output 
{{OrderBy}} from "select v1, v2, pk3" based on "order by t.v2, t.pk3". This 
work is done by {{OrderPreservingTracker}} in {{TupleProjectionPlan}} . But for 
{{OrderPreservingTracker}}, it could not support extracting partial ordering 
columns, when it finds that {{v1}} in "select v1, v2, pk3" does not appear in 
"order by t.v2, t.pk3",   {{OrderPreservingTracker.isOrderPreserving}} returns 
false, and 
{{OrderPreservingTracker.getOrderPreservingTrackInfos}} returns an empty list 
in {{TupleProjectionPlan}}. 
We should modify {{OrderPreservingTracker}} to make {{OrderPreservingTracker 
getOrderPreservingTrackInfos}} could also extract partial continuous ordering 
columns which start from the first column even if 
{{OrderPreservingTracker#isOrderPreserving}} is false.  That is, even if {{v1}} 
in {{select v1, v2, pk3}} does not appear in {{order by t.v2, t.pk3}}, it will 
return the ordered {{v2,pk3}}.

  was:
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the inner query of the second sql, we infer the output 
{{OrderBy}} from "select v1, v2, pk3" based on "order by t.v2, t.pk3". This 
work is done by {{OrderPreservingTracker}} in {{TupleProjectionPlan}} . But for 
{{OrderPreservingTracker}}, it could not support extracting partial ordering 
columns, when it finds that {{v1}} in "select v1, v2, pk3" does not appear in 
"order by t.v2, t.pk3",   {{OrderPreservingTracker.isOrderPreserving}} returns 
false, and 
{{OrderPreservingTracker.getOrderPreservingTrackInfos}} returns an empty list 
in {{TupleProjectionPlan}. 
We should modify {{OrderPreservingTracker}} to make {{OrderPreservingTracker 
getOrderPreservingTrackInfos}} could also extract partial continuous ordering 
columns which start from the first column even if 
{{OrderPreservingTracker#isOrderPreserving}} is false.  That is, even if {{v1}} 
in {{select v1, v2, pk3}} does not appear in {{order by t.v2, t.pk3}}, it will 
return the ordered {{v2,pk3}}.


> Improve OrderPreservingTracker to support extracting partial ordering columns 
> for TupleProjectionPlan 
> --
>
> Key: PHOENIX-7352
> URL: https://issues.apache.org/jira/browse/PHOENIX-7352
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.2.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Major
>
> This is an improvement for  PHOENIX-5148: 
> Given a 

[jira] [Updated] (PHOENIX-7352) Improve OrderPreservingTracker to support extracting partial ordering columns for TupleProjectionPlan

[chenglei (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenglei updated PHOENIX-7352:
--
Description: 
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the inner query of the second sql, we infer the output 
{{OrderBy}} from "select v1, v2, pk3" based on "order by t.v2, t.pk3". This 
work is done by {{OrderPreservingTracker}} in {{TupleProjectionPlan}} . But for 
{{OrderPreservingTracker}}, it could not support extracting partial ordering 
columns, when it finds that {{v1}} in "select v1, v2, pk3" does not appear in 
"order by t.v2, t.pk3",   {{OrderPreservingTracker.isOrderPreserving}} returns 
false, and 
{{OrderPreservingTracker. getOrderPreservingTrackInfos}} returns an empty list 
in {{TupleProjectionPlan}. 
We should modify {{OrderPreservingTracker}} to make {{OrderPreservingTracker 
getOrderPreservingTrackInfos}} could also extract partial continuous ordering 
columns which start from the first column even if 
{{OrderPreservingTracker#isOrderPreserving}} is false.  That is, even if {{v1}} 
in {{select v1, v2, pk3}} does not appear in {{order by t.v2, t.pk3}}, it will 
return the ordered {{v2,pk3}}.

  was:
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the inner query of the second sql, we infer the output 
{{OrderBy}} from "select v1, v2, pk3" based on "order by t.v2, t.pk3". This 
work is done by {{OrderPreservingTracker}} in {{TupleProjectionPlan}} . But for 
{{OrderPreservingTracker}}, it could not support extracting partial ordering 
columns, when it finds that {{v1}} in "select v1, v2, pk3" does not appear in 
"order by t.v2, t.pk3",  {{OrderPreservingTracker. IsOrderPreserving}} returns 
false, and 
{{OrderPreservingTracker. getOrderPreservingTrackInfos}} returns an empty list 
in {{TupleProjectionPlan}. 
We should modify {{OrderPreservingTracker}} to make {{OrderPreservingTracker 
getOrderPreservingTrackInfos}} could also extract partial continuous ordering 
columns which start from the first column even if 
{{OrderPreservingTracker#isOrderPreserving}} is false.  That is, even if {{v1}} 
in {{select v1, v2, pk3}} does not appear in {{order by t.v2, t.pk3}}, it will 
return the ordered {{v2,pk3}}.


> Improve OrderPreservingTracker to support extracting partial ordering columns 
> for TupleProjectionPlan 
> --
>
> Key: PHOENIX-7352
> URL: https://issues.apache.org/jira/browse/PHOENIX-7352
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.2.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Major
>
> This is an improvement for  PHOENIX-5148: 
> Given a 

[jira] [Updated] (PHOENIX-7352) Improve OrderPreservingTracker to support extracting partial ordering columns for TupleProjectionPlan

[chenglei (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenglei updated PHOENIX-7352:
--
Description: 
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the inner query of the second sql, we infer the output 
{{OrderBy}} from "select v1, v2, pk3" based on "order by t.v2, t.pk3". This 
work is done by {{OrderPreservingTracker}} in {{TupleProjectionPlan}} . But for 
{{OrderPreservingTracker}}, it could not support extracting partial ordering 
columns, when it finds that {{v1}} in "select v1, v2, pk3" does not appear in 
"order by t.v2, t.pk3",   {{OrderPreservingTracker.isOrderPreserving}} returns 
false, and 
{{OrderPreservingTracker.getOrderPreservingTrackInfos}} returns an empty list 
in {{TupleProjectionPlan}}. 

We should modify {{OrderPreservingTracker}} to make 
{{OrderPreservingTracker.getOrderPreservingTrackInfos}} could also extract 
partial continuous ordering columns which start from the first column even if 
{{OrderPreservingTracker.isOrderPreserving}} is false.  That is to say, even if 
{{v1}} in "select v1, v2, pk3" does not appear in "order by t.v2, t.pk3", it 
will return the ordered {{v2,pk3}}.

  was:
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the inner query of the second sql, we infer the output 
{{OrderBy}} from "select v1, v2, pk3" based on "order by t.v2, t.pk3". This 
work is done by {{OrderPreservingTracker}} in {{TupleProjectionPlan}} . But for 
{{OrderPreservingTracker}}, it could not support extracting partial ordering 
columns, when it finds that {{v1}} in "select v1, v2, pk3" does not appear in 
"order by t.v2, t.pk3",   {{OrderPreservingTracker.isOrderPreserving}} returns 
false, and 
{{OrderPreservingTracker.getOrderPreservingTrackInfos}} returns an empty list 
in {{TupleProjectionPlan}}. 
We should modify {{OrderPreservingTracker}} to make {{OrderPreservingTracker 
getOrderPreservingTrackInfos}} could also extract partial continuous ordering 
columns which start from the first column even if 
{{OrderPreservingTracker#isOrderPreserving}} is false.  That is, even if {{v1}} 
in {{select v1, v2, pk3}} does not appear in {{order by t.v2, t.pk3}}, it will 
return the ordered {{v2,pk3}}.


> Improve OrderPreservingTracker to support extracting partial ordering columns 
> for TupleProjectionPlan 
> --
>
> Key: PHOENIX-7352
> URL: https://issues.apache.org/jira/browse/PHOENIX-7352
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.2.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Major
>
> This is an improvement for  PHOENIX-5148: 
> 

[jira] [Updated] (PHOENIX-7352) Improve OrderPreservingTracker to support extracting partial ordering columns for TupleProjectionPlan

[chenglei (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenglei updated PHOENIX-7352:
--
Description: 
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the inner query of the second sql, we infer the output 
{{OrderBy}} from "select v1, v2, pk3" based on "order by t.v2, t.pk3". This 
work is done by {{OrderPreservingTracker}} in {{TupleProjectionPlan}} . But for 
{{OrderPreservingTracker}}, it could not support extracting partial ordering 
columns, when it finds that {{v1}} in "select v1, v2, pk3" does not appear in 
"order by t.v2, t.pk3",   {{OrderPreservingTracker.isOrderPreserving}} returns 
false, and 
{{OrderPreservingTracker.getOrderPreservingTrackInfos}} returns an empty list 
in {{TupleProjectionPlan}. 
We should modify {{OrderPreservingTracker}} to make {{OrderPreservingTracker 
getOrderPreservingTrackInfos}} could also extract partial continuous ordering 
columns which start from the first column even if 
{{OrderPreservingTracker#isOrderPreserving}} is false.  That is, even if {{v1}} 
in {{select v1, v2, pk3}} does not appear in {{order by t.v2, t.pk3}}, it will 
return the ordered {{v2,pk3}}.

  was:
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the inner query of the second sql, we infer the output 
{{OrderBy}} from "select v1, v2, pk3" based on "order by t.v2, t.pk3". This 
work is done by {{OrderPreservingTracker}} in {{TupleProjectionPlan}} . But for 
{{OrderPreservingTracker}}, it could not support extracting partial ordering 
columns, when it finds that {{v1}} in "select v1, v2, pk3" does not appear in 
"order by t.v2, t.pk3",   {{OrderPreservingTracker.isOrderPreserving}} returns 
false, and 
{{OrderPreservingTracker. getOrderPreservingTrackInfos}} returns an empty list 
in {{TupleProjectionPlan}. 
We should modify {{OrderPreservingTracker}} to make {{OrderPreservingTracker 
getOrderPreservingTrackInfos}} could also extract partial continuous ordering 
columns which start from the first column even if 
{{OrderPreservingTracker#isOrderPreserving}} is false.  That is, even if {{v1}} 
in {{select v1, v2, pk3}} does not appear in {{order by t.v2, t.pk3}}, it will 
return the ordered {{v2,pk3}}.


> Improve OrderPreservingTracker to support extracting partial ordering columns 
> for TupleProjectionPlan 
> --
>
> Key: PHOENIX-7352
> URL: https://issues.apache.org/jira/browse/PHOENIX-7352
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.2.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Major
>
> This is an improvement for  PHOENIX-5148: 
> Given a 

[jira] [Updated] (PHOENIX-7352) Improve OrderPreservingTracker to support extracting partial ordering columns for TupleProjectionPlan

[chenglei (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenglei updated PHOENIX-7352:
--
Description: 
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the inner query of the second sql, we infer the output 
{{OrderBy}} from "select v1, v2, pk3" based on "order by t.v2, t.pk3". This 
work is done by {{OrderPreservingTracker}} in {{TupleProjectionPlan}} . But for 
{{OrderPreservingTracker}}, it could not support extracting partial ordering 
columns, when it finds that {{v1}} in "select v1, v2, pk3" does not appear in 
"order by t.v2, t.pk3",  {{OrderPreservingTracker. IsOrderPreserving}} returns 
false, and 
{{OrderPreservingTracker. getOrderPreservingTrackInfos}} returns an empty list 
in {{TupleProjectionPlan}. 
We should modify {{OrderPreservingTracker}} to make {{OrderPreservingTracker 
getOrderPreservingTrackInfos}} could also extract partial continuous ordering 
columns which start from the first column even if 
{{OrderPreservingTracker#isOrderPreserving}} is false.  That is, even if {{v1}} 
in {{select v1, v2, pk3}} does not appear in {{order by t.v2, t.pk3}}, it will 
return the ordered {{v2,pk3}}.

  was:
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the inner query of the second sql, we infer the output 
{{OrderBy}} from "select v1, v2, pk3" based on "order by t.v2, t.pk3". This 
work is done by {{OrderPreservingTracker}} in {{TupleProjectionPlan}} . But for 
{{OrderPreservingTracker}}, it could not support extracting partial ordering 
columns, when it finds that {{v1}} in "select v1, v2, pk3" does not appear in 
"order by t.v2, t.pk3", {{OrderPreservingTracker. IsOrderPreserving}} returns 
false, and 
{{OrderPreservingTracker. getOrderPreservingTrackInfos}} returns an empty list 
in {{TupleProjectionPlan}. 
We should modify {{OrderPreservingTracker}} to make {{OrderPreservingTracker 
getOrderPreservingTrackInfos}} could also extract partial continuous ordering 
columns which start from the first column even if 
{{OrderPreservingTracker#isOrderPreserving}} is false.  That is, even if {{v1}} 
in {{select v1, v2, pk3}} does not appear in {{order by t.v2, t.pk3}}, it will 
return the ordered {{v2,pk3}}.


> Improve OrderPreservingTracker to support extracting partial ordering columns 
> for TupleProjectionPlan 
> --
>
> Key: PHOENIX-7352
> URL: https://issues.apache.org/jira/browse/PHOENIX-7352
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.2.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Major
>
> This is an improvement for  PHOENIX-5148: 
> Given a 

[jira] [Updated] (PHOENIX-7352) Improve OrderPreservingTracker to support extracting partial ordering columns for TupleProjectionPlan

[chenglei (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenglei updated PHOENIX-7352:
--
Description: 
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the inner query of the second sql, we infer the output 
{{OrderBy}} from "select v1, v2, pk3" based on "order by t.v2, t.pk3". This 
work is done by {{OrderPreservingTracker}} in {{TupleProjectionPlan}} . But for 
{{OrderPreservingTracker}}, it could not support extracting partial ordering 
columns, when it finds that {{v1}} in "select v1, v2, pk3" does not appear in 
"order by t.v2, t.pk3", {{OrderPreservingTracker. IsOrderPreserving}} returns 
false, and 
{{OrderPreservingTracker. getOrderPreservingTrackInfos}} returns an empty list 
in {{TupleProjectionPlan}. 
We should modify {{OrderPreservingTracker}} to make {{OrderPreservingTracker 
getOrderPreservingTrackInfos}} could also extract partial continuous ordering 
columns which start from the first column even if 
{{OrderPreservingTracker#isOrderPreserving}} is false.  That is, even if {{v1}} 
in {{select v1, v2, pk3}} does not appear in {{order by t.v2, t.pk3}}, it will 
return the ordered {{v2,pk3}}.

  was:
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the inner query of the second sql, we infer the output 
{{OrderBy}} from "select v1, v2, pk3" based on "order by t.v2, t.pk3". This 
work is done by {{OrderPreservingTracker}} in {{TupleProjectionPlan}} . But for 
{{OrderPreservingTracker}}, it could not support extracting partial ordering 
columns, when it finds that {{v1}} in {{select v1, v2, pk3}} does not appear in 
{{order by t.v2, t.pk3}}, {{OrderPreservingTracker. IsOrderPreserving}} returns 
false, and 
{{OrderPreservingTracker. getOrderPreservingTrackInfos}} returns an empty list 
in {{TupleProjectionPlan}. 
We should modify {{OrderPreservingTracker}} to make {{OrderPreservingTracker 
getOrderPreservingTrackInfos}} could also extract partial continuous ordering 
columns which start from the first column even if 
{{OrderPreservingTracker#isOrderPreserving}} is false.  That is, even if {{v1}} 
in {{select v1, v2, pk3}} does not appear in {{order by t.v2, t.pk3}}, it will 
return the ordered {{v2,pk3}}.


> Improve OrderPreservingTracker to support extracting partial ordering columns 
> for TupleProjectionPlan 
> --
>
> Key: PHOENIX-7352
> URL: https://issues.apache.org/jira/browse/PHOENIX-7352
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.2.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Major
>
> This is an improvement for  PHOENIX-5148: 
> Given 

[jira] [Updated] (PHOENIX-7352) Improve OrderPreservingTracker to support extracting partial ordering columns for TupleProjectionPlan

[chenglei (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenglei updated PHOENIX-7352:
--
Description: 
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the inner query of the second sql, we infer the output 
{{OrderBy}} from "select v1, v2, pk3" based on "order by t.v2, t.pk3". This 
work is done by {{OrderPreservingTracker}} in {{TupleProjectionPlan}} . But for 
{{OrderPreservingTracker}}, it could not support extracting partial ordering 
columns. That is to say, when it finds that {{v1}} in {{select v1, v2, pk3}} 
does not appear in {{order by t.v2, t.pk3}}, {{OrderPreservingTracker. 
IsOrderPreserving}} returns false, and 
{{OrderPreservingTracker. getOrderPreservingTrackInfos}} returns an empty list 
in {{TupleProjectionPlan}. 
We should modify {{OrderPreservingTracker}} to make {{OrderPreservingTracker 
getOrderPreservingTrackInfos}} could also extract partial continuous ordering 
columns which start from the first column even if 
{{OrderPreservingTracker#isOrderPreserving}} is false.  That is, even if {{v1}} 
in {{select v1, v2, pk3}} does not appear in {{order by t.v2, t.pk3}}, it will 
return the ordered {{v2,pk3}}.

  was:
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the inner query of the second sql, we infer the output 
{{OrderBy}} from {{select v1, v2, pk3}} based on {{order by t.v2, t.pk3}}. This 
work is done by {{OrderPreservingTracker}} in {{TupleProjectionPlan}} . But for 
{{OrderPreservingTracker}}, it could not support extracting partial ordering 
columns. That is to say, when it finds that {{v1}} in {{select v1, v2, pk3}} 
does not appear in {{order by t.v2, t.pk3}}, {{OrderPreservingTracker. 
IsOrderPreserving}} returns false, and 
{{OrderPreservingTracker. getOrderPreservingTrackInfos}} returns an empty list 
in {{TupleProjectionPlan}. 
We should modify {{OrderPreservingTracker}} to make {{OrderPreservingTracker 
getOrderPreservingTrackInfos}} could also extract partial continuous ordering 
columns which start from the first column even if 
{{OrderPreservingTracker#isOrderPreserving}} is false.  That is, even if {{v1}} 
in {{select v1, v2, pk3}} does not appear in {{order by t.v2, t.pk3}}, it will 
return the ordered {{v2,pk3}}.


> Improve OrderPreservingTracker to support extracting partial ordering columns 
> for TupleProjectionPlan 
> --
>
> Key: PHOENIX-7352
> URL: https://issues.apache.org/jira/browse/PHOENIX-7352
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.2.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Major
>
> This is an 

[jira] [Updated] (PHOENIX-7352) Improve OrderPreservingTracker to support extracting partial ordering columns for TupleProjectionPlan

[chenglei (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenglei updated PHOENIX-7352:
--
Description: 
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the inner query of the second sql, we infer the output 
{{OrderBy}} from "select v1, v2, pk3" based on "order by t.v2, t.pk3". This 
work is done by {{OrderPreservingTracker}} in {{TupleProjectionPlan}} . But for 
{{OrderPreservingTracker}}, it could not support extracting partial ordering 
columns, when it finds that {{v1}} in {{select v1, v2, pk3}} does not appear in 
{{order by t.v2, t.pk3}}, {{OrderPreservingTracker. IsOrderPreserving}} returns 
false, and 
{{OrderPreservingTracker. getOrderPreservingTrackInfos}} returns an empty list 
in {{TupleProjectionPlan}. 
We should modify {{OrderPreservingTracker}} to make {{OrderPreservingTracker 
getOrderPreservingTrackInfos}} could also extract partial continuous ordering 
columns which start from the first column even if 
{{OrderPreservingTracker#isOrderPreserving}} is false.  That is, even if {{v1}} 
in {{select v1, v2, pk3}} does not appear in {{order by t.v2, t.pk3}}, it will 
return the ordered {{v2,pk3}}.

  was:
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the inner query of the second sql, we infer the output 
{{OrderBy}} from "select v1, v2, pk3" based on "order by t.v2, t.pk3". This 
work is done by {{OrderPreservingTracker}} in {{TupleProjectionPlan}} . But for 
{{OrderPreservingTracker}}, it could not support extracting partial ordering 
columns. That is to say, when it finds that {{v1}} in {{select v1, v2, pk3}} 
does not appear in {{order by t.v2, t.pk3}}, {{OrderPreservingTracker. 
IsOrderPreserving}} returns false, and 
{{OrderPreservingTracker. getOrderPreservingTrackInfos}} returns an empty list 
in {{TupleProjectionPlan}. 
We should modify {{OrderPreservingTracker}} to make {{OrderPreservingTracker 
getOrderPreservingTrackInfos}} could also extract partial continuous ordering 
columns which start from the first column even if 
{{OrderPreservingTracker#isOrderPreserving}} is false.  That is, even if {{v1}} 
in {{select v1, v2, pk3}} does not appear in {{order by t.v2, t.pk3}}, it will 
return the ordered {{v2,pk3}}.


> Improve OrderPreservingTracker to support extracting partial ordering columns 
> for TupleProjectionPlan 
> --
>
> Key: PHOENIX-7352
> URL: https://issues.apache.org/jira/browse/PHOENIX-7352
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.2.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Major
>
> This is an improvement for  

[jira] [Updated] (PHOENIX-7352) Improve OrderPreservingTracker to support extracting partial ordering columns for TupleProjectionPlan

[chenglei (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenglei updated PHOENIX-7352:
--
Description: 
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the inner query of the second sql, we infer the output 
{{OrderBy}} from {{select v1, v2, pk3}} based on {{order by t.v2, t.pk3}}. This 
work is done by {{OrderPreservingTracker}} in {{TupleProjectionPlan}} . But for 
{{OrderPreservingTracker}}, it could not support extracting partial ordering 
columns. That is to say, when it finds that {{v1}} in {{select v1, v2, pk3}} 
does not appear in {{order by t.v2, t.pk3}}, {{OrderPreservingTracker. 
IsOrderPreserving}} returns false, and 
{{OrderPreservingTracker. getOrderPreservingTrackInfos}} returns an empty list 
in {{TupleProjectionPlan}. 
We should modify {{OrderPreservingTracker}} to make {{OrderPreservingTracker 
getOrderPreservingTrackInfos}} could also extract partial continuous ordering 
columns which start from the first column even if 
{{OrderPreservingTracker#isOrderPreserving}} is false.  That is, even if {{v1}} 
in {{select v1, v2, pk3}} does not appear in {{order by t.v2, t.pk3}}, it will 
return the ordered {{v2,pk3}}.

  was:
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the inner query of the second sql, we infer the output 
{{OrderBy}} from {{select v1, v2, pk3}} based on {{order by t.v2, t.pk3}}. This 
work is done by {{OrderPreservingTracker}} in {{TupleProjectionPlan}} . But for 
{{OrderPreservingTracker}}, it could not support extracting partial ordering 
columns. That is to say, when it finds that {{v1}} in {{select v1, v2, pk3}} 
does not appear in {{order by t.v2, t.pk3}}, {{OrderPreservingTracker. 
IsOrderPreserving}} returns false, and 
{{OrderPreservingTracker. getOrderPreservingTrackInfos}} returns an empty list 
in {{TupleProjectionPlan}. 
We should modify {{OrderPreservingTracker}} and even in 
{{OrderPreservingTracker. IsOrderPreserving}} is false, 
{{OrderPreservingTracker getOrderPreservingTrackInfos}} could also return 
partial of a sequence, That is, even if v1 in {{select v1, v2,pk3}} does not 
appear in {{order by t.v2, t.pk3}}, it will return the ordered {{v2,pk3}}


> Improve OrderPreservingTracker to support extracting partial ordering columns 
> for TupleProjectionPlan 
> --
>
> Key: PHOENIX-7352
> URL: https://issues.apache.org/jira/browse/PHOENIX-7352
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.2.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Major
>
> This is an improvement for  PHOENIX-5148: 
> Given a table:
> 

[jira] [Updated] (PHOENIX-7352) Improve OrderPreservingTracker to support extracting partial ordering columns for TupleProjectionPlan

[chenglei (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenglei updated PHOENIX-7352:
--
Description: 
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the inner query of the second sql, we infer the output 
{{OrderBy}} from {{select v1, v2, pk3}} based on {{order by t.v2, t.pk3}}. This 
work is done by {{OrderPreservingTracker}} in {{TupleProjectionPlan}} . But for 
{{OrderPreservingTracker}}, it could not support extracting partial ordering 
columns. That is to say, when it finds that {{v1}} in {{select v1, v2, pk3}} 
does not appear in {{order by t.v2, t.pk3}}, {{OrderPreservingTracker. 
IsOrderPreserving}} returns false, and 
{{OrderPreservingTracker. getOrderPreservingTrackInfos}} returns an empty list 
in {{TupleProjectionPlan}. 
We should modify {{OrderPreservingTracker}} and even in 
{{OrderPreservingTracker. IsOrderPreserving}} is false, 
{{OrderPreservingTracker getOrderPreservingTrackInfos}} could also return 
partial of a sequence, That is, even if v1 in {{select v1, v2,pk3}} does not 
appear in {{order by t.v2, t.pk3}}, it will return the ordered {{v2,pk3}}

  was:
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the inner query of the second sql, we infer the output 
{{OrderBy}} from {{select v1, v2, pk3}} based on {{}order by t.v2, t.pk3}}. 
This work is done by {{OrderPreservingTracker}} in {{TupleProjectionPlan}}, but 
for {{OrderPreservingTracker}}, it could not support 


> Improve OrderPreservingTracker to support extracting partial ordering columns 
> for TupleProjectionPlan 
> --
>
> Key: PHOENIX-7352
> URL: https://issues.apache.org/jira/browse/PHOENIX-7352
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.2.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Major
>
> This is an improvement for  PHOENIX-5148: 
> Given a table:
> {code:java}
>   create table test ( 
>pk1 varchar not null , 
>pk2 varchar not null, 
>pk3 varchar not null,
>v1 varchar, 
>v2 varchar, 
>CONSTRAINT TEST_PK PRIMARY KEY ( 
>  pk1,
>  pk2,
>  pk3 ))
> {code}
> PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
> v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, 
> t.pk3, t.v1":
> {code:java}
> select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
> t.pk3, t.v1 limit 10) a order by v2, pk3
> {code}
> But if we make a small change to the sql above, just remove the {{t.v1}} in  
> inner query {{OrderBy}} "order by 

[jira] [Updated] (PHOENIX-7352) Improve OrderPreservingTracker to support extracting partial ordering columns for TupleProjectionPlan

[chenglei (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenglei updated PHOENIX-7352:
--
Description: 
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the inner query of the second sql, we infer the output 
{{OrderBy}} from {{select v1, v2, pk3}} based on {{}order by t.v2, t.pk3}}. 
This work is done by {{OrderPreservingTracker}} in {{TupleProjectionPlan}}, but 
for {{OrderPreservingTracker}}, it could not support 

  was:
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the second sql, we infer the output {{OrderBy}} for the 
inner query in {{OrderPreservingTracker}} by {{OrderPreservingTracker}}, but  
{{OrderPreservingTracker}} could not support 


> Improve OrderPreservingTracker to support extracting partial ordering columns 
> for TupleProjectionPlan 
> --
>
> Key: PHOENIX-7352
> URL: https://issues.apache.org/jira/browse/PHOENIX-7352
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.2.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Major
>
> This is an improvement for  PHOENIX-5148: 
> Given a table:
> {code:java}
>   create table test ( 
>pk1 varchar not null , 
>pk2 varchar not null, 
>pk3 varchar not null,
>v1 varchar, 
>v2 varchar, 
>CONSTRAINT TEST_PK PRIMARY KEY ( 
>  pk1,
>  pk2,
>  pk3 ))
> {code}
> PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
> v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, 
> t.pk3, t.v1":
> {code:java}
> select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
> t.pk3, t.v1 limit 10) a order by v2, pk3
> {code}
> But if we make a small change to the sql above, just remove the {{t.v1}} in  
> inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
> {code:java}
> select v1 from (select v1, v2, pk3 from test t where pk1 = '6' order by t.v2, 
> t.pk3 limit 10) a order by v2, pk3
> {code}
> Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled 
> out because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
> unfortunately it could not be compiled out now.
> That is because for the inner query of the second sql, we infer the output 
> {{OrderBy}} from {{select v1, v2, pk3}} based on {{}order by t.v2, t.pk3}}. 
> This work is done by {{OrderPreservingTracker}} in {{TupleProjectionPlan}}, 
> but for {{OrderPreservingTracker}}, it could not support 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (PHOENIX-7352) Improve OrderPreservingTracker to support extracting partial ordering columns for TupleProjectionPlan

[chenglei (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenglei updated PHOENIX-7352:
--
Description: 
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the second sql, we infer the output {{OrderBy}} for the 
inner query in {{}} by {{OrderPreservingTracker}}, but  
{{OrderPreservingTracker}} could not support 

  was:
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.


> Improve OrderPreservingTracker to support extracting partial ordering columns 
> for TupleProjectionPlan 
> --
>
> Key: PHOENIX-7352
> URL: https://issues.apache.org/jira/browse/PHOENIX-7352
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.2.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Major
>
> This is an improvement for  PHOENIX-5148: 
> Given a table:
> {code:java}
>   create table test ( 
>pk1 varchar not null , 
>pk2 varchar not null, 
>pk3 varchar not null,
>v1 varchar, 
>v2 varchar, 
>CONSTRAINT TEST_PK PRIMARY KEY ( 
>  pk1,
>  pk2,
>  pk3 ))
> {code}
> PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
> v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, 
> t.pk3, t.v1":
> {code:java}
> select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by t.v2, 
> t.pk3, t.v1 limit 10) a order by v2, pk3
> {code}
> But if we make a small change to the sql above, just remove the {{t.v1}} in  
> inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
> {code:java}
> select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by t.v2, 
> t.pk3 limit 10) a order by v2, pk3
> {code}
> Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled 
> out because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
> unfortunately it could not be compiled out now.
> That is because for the second sql, we infer the output {{OrderBy}} for the 
> inner query in {{}} by {{OrderPreservingTracker}}, but  
> {{OrderPreservingTracker}} could not support 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (PHOENIX-7352) Improve OrderPreservingTracker to support extracting partial ordering columns for TupleProjectionPlan

[chenglei (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenglei updated PHOENIX-7352:
--
Description: 
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the second sql, we infer the output {{OrderBy}} for the 
inner query in {{OrderPreservingTracker}} by {{OrderPreservingTracker}}, but  
{{OrderPreservingTracker}} could not support 

  was:
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

That is because for the second sql, we infer the output {{OrderBy}} for the 
inner query in {{}} by {{OrderPreservingTracker}}, but  
{{OrderPreservingTracker}} could not support 


> Improve OrderPreservingTracker to support extracting partial ordering columns 
> for TupleProjectionPlan 
> --
>
> Key: PHOENIX-7352
> URL: https://issues.apache.org/jira/browse/PHOENIX-7352
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.2.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Major
>
> This is an improvement for  PHOENIX-5148: 
> Given a table:
> {code:java}
>   create table test ( 
>pk1 varchar not null , 
>pk2 varchar not null, 
>pk3 varchar not null,
>v1 varchar, 
>v2 varchar, 
>CONSTRAINT TEST_PK PRIMARY KEY ( 
>  pk1,
>  pk2,
>  pk3 ))
> {code}
> PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
> v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, 
> t.pk3, t.v1":
> {code:java}
> select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by t.v2, 
> t.pk3, t.v1 limit 10) a order by v2, pk3
> {code}
> But if we make a small change to the sql above, just remove the {{t.v1}} in  
> inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
> {code:java}
> select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by t.v2, 
> t.pk3 limit 10) a order by v2, pk3
> {code}
> Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled 
> out because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
> unfortunately it could not be compiled out now.
> That is because for the second sql, we infer the output {{OrderBy}} for the 
> inner query in {{OrderPreservingTracker}} by {{OrderPreservingTracker}}, but  
> {{OrderPreservingTracker}} could not support 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (PHOENIX-7352) Improve OrderPreservingTracker to support extracting partial ordering columns for TupleProjectionPlan

[chenglei (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenglei updated PHOENIX-7352:
--
Description: 
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, t.pk3, 
t.v1":
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3, t.v1 limit 10) a order by v2, pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by t.v2, 
t.pk3 limit 10) a order by v2, pk3
{code}
Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled out 
because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
unfortunately it could not be compiled out now.

  was:
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2,pk3" because it matchs the inner query {{OrderBy}} "order by 
t.v2,t.pk3,t.v1":
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
t.v2,t.pk3,t.v1 limit 10) a order by v2,pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query OrderBy {{order by t.v2,t.pk3,t.v1}}:
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
t.v2,t.pk3 limit 10) a order by v2,pk3
{code}
Obviously, the outer {{OrderBy}} {{order by v2,pk3}} should be compiled out 
because it matchs the inner query OrderBy {{order by t.v2,t.pk3}} , but 
unfortunately it could not be compiled out now.


> Improve OrderPreservingTracker to support extracting partial ordering columns 
> for TupleProjectionPlan 
> --
>
> Key: PHOENIX-7352
> URL: https://issues.apache.org/jira/browse/PHOENIX-7352
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.2.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Major
>
> This is an improvement for  PHOENIX-5148: 
> Given a table:
> {code:java}
>   create table test ( 
>pk1 varchar not null , 
>pk2 varchar not null, 
>pk3 varchar not null,
>v1 varchar, 
>v2 varchar, 
>CONSTRAINT TEST_PK PRIMARY KEY ( 
>  pk1,
>  pk2,
>  pk3 ))
> {code}
> PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
> v2, pk3" because it matches the inner query {{OrderBy}} "order by t.v2, 
> t.pk3, t.v1":
> {code:java}
> select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by t.v2, 
> t.pk3, t.v1 limit 10) a order by v2, pk3
> {code}
> But if we make a small change to the sql above, just remove the {{t.v1}} in  
> inner query {{OrderBy}} "order by t.v2, t.pk3, t.v1":
> {code:java}
> select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by t.v2, 
> t.pk3 limit 10) a order by v2, pk3
> {code}
> Obviously, the outer {{OrderBy}} "order by v2,pk3" should still be compiled 
> out because it matches the inner query OrderBy "order by t.v2, t.pk3" , but 
> unfortunately it could not be compiled out now.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (PHOENIX-7352) Improve OrderPreservingTracker to support extracting partial ordering columns for TupleProjectionPlan

[chenglei (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenglei updated PHOENIX-7352:
--
Description: 
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2,pk3" because it matchs the inner query {{OrderBy}} "order by 
t.v2,t.pk3,t.v1":
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
t.v2,t.pk3,t.v1 limit 10) a order by v2,pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query OrderBy {{order by t.v2,t.pk3,t.v1}}:
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
t.v2,t.pk3 limit 10) a order by v2,pk3
{code}
Obviously, the outer {{OrderBy}} {{order by v2,pk3}} should be compiled out 
because it matchs the inner query OrderBy {{order by t.v2,t.pk3}} , but 
unfortunately it could not be compiled out now.

  was:
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2,pk3":
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
t.v2,t.pk3,t.v1 limit 10) a order by v2,pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query OrderBy {{order by t.v2,t.pk3,t.v1}}:
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
t.v2,t.pk3 limit 10) a order by v2,pk3
{code}
Obviously, the outer {{OrderBy}} {{order by v2,pk3}} should be compiled out 
because it matchs the inner query OrderBy {{order by t.v2,t.pk3}} , but 
unfortunately it could not be compiled out now.


> Improve OrderPreservingTracker to support extracting partial ordering columns 
> for TupleProjectionPlan 
> --
>
> Key: PHOENIX-7352
> URL: https://issues.apache.org/jira/browse/PHOENIX-7352
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.2.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Major
>
> This is an improvement for  PHOENIX-5148: 
> Given a table:
> {code:java}
>   create table test ( 
>pk1 varchar not null , 
>pk2 varchar not null, 
>pk3 varchar not null,
>v1 varchar, 
>v2 varchar, 
>CONSTRAINT TEST_PK PRIMARY KEY ( 
>  pk1,
>  pk2,
>  pk3 ))
> {code}
> PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
> v2,pk3" because it matchs the inner query {{OrderBy}} "order by 
> t.v2,t.pk3,t.v1":
> {code:java}
> select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
> t.v2,t.pk3,t.v1 limit 10) a order by v2,pk3
> {code}
> But if we make a small change to the sql above, just remove the {{t.v1}} in  
> inner query OrderBy {{order by t.v2,t.pk3,t.v1}}:
> {code:java}
> select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
> t.v2,t.pk3 limit 10) a order by v2,pk3
> {code}
> Obviously, the outer {{OrderBy}} {{order by v2,pk3}} should be compiled out 
> because it matchs the inner query OrderBy {{order by t.v2,t.pk3}} , but 
> unfortunately it could not be compiled out now.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (PHOENIX-7352) Improve OrderPreservingTracker to support extracting partial ordering columns for TupleProjectionPlan

[chenglei (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenglei updated PHOENIX-7352:
--
Description: 
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
v2,pk3":
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
t.v2,t.pk3,t.v1 limit 10) a order by v2,pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query OrderBy {{order by t.v2,t.pk3,t.v1}}:
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
t.v2,t.pk3 limit 10) a order by v2,pk3
{code}
Obviously, the outer {{OrderBy}} {{order by v2,pk3}} should be compiled out 
because it matchs the inner query OrderBy {{order by t.v2,t.pk3}} , but 
unfortunately it could not be compiled out now.

  was:
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  {{order by 
v2,pk3}}:
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
t.v2,t.pk3,t.v1 limit 10) a order by v2,pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query OrderBy {{order by t.v2,t.pk3,t.v1}}:
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
t.v2,t.pk3 limit 10) a order by v2,pk3
{code}
Obviously, the outer {{OrderBy}} {{order by v2,pk3}} should be compiled out 
because it matchs the inner query OrderBy {{order by t.v2,t.pk3}} , but 
unfortunately it could not be compiled out now.


> Improve OrderPreservingTracker to support extracting partial ordering columns 
> for TupleProjectionPlan 
> --
>
> Key: PHOENIX-7352
> URL: https://issues.apache.org/jira/browse/PHOENIX-7352
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.2.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Major
>
> This is an improvement for  PHOENIX-5148: 
> Given a table:
> {code:java}
>   create table test ( 
>pk1 varchar not null , 
>pk2 varchar not null, 
>pk3 varchar not null,
>v1 varchar, 
>v2 varchar, 
>CONSTRAINT TEST_PK PRIMARY KEY ( 
>  pk1,
>  pk2,
>  pk3 ))
> {code}
> PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  "order by 
> v2,pk3":
> {code:java}
> select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
> t.v2,t.pk3,t.v1 limit 10) a order by v2,pk3
> {code}
> But if we make a small change to the sql above, just remove the {{t.v1}} in  
> inner query OrderBy {{order by t.v2,t.pk3,t.v1}}:
> {code:java}
> select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
> t.v2,t.pk3 limit 10) a order by v2,pk3
> {code}
> Obviously, the outer {{OrderBy}} {{order by v2,pk3}} should be compiled out 
> because it matchs the inner query OrderBy {{order by t.v2,t.pk3}} , but 
> unfortunately it could not be compiled out now.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (PHOENIX-7352) Improve OrderPreservingTracker to support extracting partial ordering columns for TupleProjectionPlan

[chenglei (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenglei updated PHOENIX-7352:
--
Description: 
This is an improvement for  PHOENIX-5148: 
Given a table:
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  {{order by 
v2,pk3}}:
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
t.v2,t.pk3,t.v1 limit 10) a order by v2,pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query OrderBy {{order by t.v2,t.pk3,t.v1}}:
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
t.v2,t.pk3 limit 10) a order by v2,pk3
{code}
Obviously, the outer {{OrderBy}} {{order by v2,pk3}} should be compiled out 
because it matchs the inner query OrderBy {{order by t.v2,t.pk3}} , but 
unfortunately it could not be compiled out now.

  was:
This is an improvement for  PHOENIX-5148: 
Given a table
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  {{order by 
v2,pk3}}:
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
t.v2,t.pk3,t.v1 limit 10) a order by v2,pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query OrderBy {{order by t.v2,t.pk3,t.v1}}:
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
t.v2,t.pk3 limit 10) a order by v2,pk3
{code}
Obviously, the outer {{OrderBy}} {{order by v2,pk3}} should be compiled out 
because it matchs the inner query OrderBy {{order by t.v2,t.pk3}} , but 
unfortunately it could not be compiled out now.


> Improve OrderPreservingTracker to support extracting partial ordering columns 
> for TupleProjectionPlan 
> --
>
> Key: PHOENIX-7352
> URL: https://issues.apache.org/jira/browse/PHOENIX-7352
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.2.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Major
>
> This is an improvement for  PHOENIX-5148: 
> Given a table:
> {code:java}
>   create table test ( 
>pk1 varchar not null , 
>pk2 varchar not null, 
>pk3 varchar not null,
>v1 varchar, 
>v2 varchar, 
>CONSTRAINT TEST_PK PRIMARY KEY ( 
>  pk1,
>  pk2,
>  pk3 ))
> {code}
> PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  {{order by 
> v2,pk3}}:
> {code:java}
> select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
> t.v2,t.pk3,t.v1 limit 10) a order by v2,pk3
> {code}
> But if we make a small change to the sql above, just remove the {{t.v1}} in  
> inner query OrderBy {{order by t.v2,t.pk3,t.v1}}:
> {code:java}
> select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
> t.v2,t.pk3 limit 10) a order by v2,pk3
> {code}
> Obviously, the outer {{OrderBy}} {{order by v2,pk3}} should be compiled out 
> because it matchs the inner query OrderBy {{order by t.v2,t.pk3}} , but 
> unfortunately it could not be compiled out now.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (PHOENIX-7352) Improve OrderPreservingTracker to support extracting partial ordering columns for TupleProjectionPlan

[chenglei (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenglei updated PHOENIX-7352:
--
Description: 
This is an improvement for  PHOENIX-5148: 
Given a table
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  {{order by 
v2,pk3}}:
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
t.v2,t.pk3,t.v1 limit 10) a order by v2,pk3
{code}
But if we make a small change to the sql above, just remove the {{t.v1}} in  
inner query OrderBy {{order by t.v2,t.pk3,t.v1}}:
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
t.v2,t.pk3 limit 10) a order by v2,pk3
{code}
Obviously, the outer {{OrderBy}} {{order by v2,pk3}} should be compiled out 
because it matchs the inner query OrderBy {{order by t.v2,t.pk3}} , but 
unfortunately it could not be compiled out now.

  was:
This is an improvement for  PHOENIX-5148: 
Given a table
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  {{order by 
v2,pk3}}:
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
t.v2,t.pk3,t.v1 limit 10) a order by v2,pk3
{code}
But if we , the outer {{OrderBy}} "order by v2,pk3" should be compiled out 
because it matchs the inner query {{OrderBy}} "order by t.v2,t.pk3,t.v1" , but 
unfortunately it is not compiled out.


> Improve OrderPreservingTracker to support extracting partial ordering columns 
> for TupleProjectionPlan 
> --
>
> Key: PHOENIX-7352
> URL: https://issues.apache.org/jira/browse/PHOENIX-7352
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.2.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Major
>
> This is an improvement for  PHOENIX-5148: 
> Given a table
> {code:java}
>   create table test ( 
>pk1 varchar not null , 
>pk2 varchar not null, 
>pk3 varchar not null,
>v1 varchar, 
>v2 varchar, 
>CONSTRAINT TEST_PK PRIMARY KEY ( 
>  pk1,
>  pk2,
>  pk3 ))
> {code}
> PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  {{order by 
> v2,pk3}}:
> {code:java}
> select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
> t.v2,t.pk3,t.v1 limit 10) a order by v2,pk3
> {code}
> But if we make a small change to the sql above, just remove the {{t.v1}} in  
> inner query OrderBy {{order by t.v2,t.pk3,t.v1}}:
> {code:java}
> select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
> t.v2,t.pk3 limit 10) a order by v2,pk3
> {code}
> Obviously, the outer {{OrderBy}} {{order by v2,pk3}} should be compiled out 
> because it matchs the inner query OrderBy {{order by t.v2,t.pk3}} , but 
> unfortunately it could not be compiled out now.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (PHOENIX-7352) Improve OrderPreservingTracker to support extracting partial ordering columns for TupleProjectionPlan

[chenglei (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenglei updated PHOENIX-7352:
--
Description: 
This is an improvement for  PHOENIX-5148: 
Given a table
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  {{order by 
v2,pk3}}:
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
t.v2,t.pk3,t.v1 limit 10) a order by v2,pk3
{code}
But if we , the outer {{OrderBy}} "order by v2,pk3" should be compiled out 
because it matchs the inner query {{OrderBy}} "order by t.v2,t.pk3,t.v1" , but 
unfortunately it is not compiled out.

  was:
This is an improvement for  PHOENIX-5148: 
Given a table
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimize following sql to compile outer {{OrderBy}}  {{order by 
v2,pk3}}:
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
t.v2,t.pk3,t.v1 limit 10) a order by v2,pk3
{code}
But if we , the outer {{OrderBy}} "order by v2,pk3" should be compiled out 
because it matchs the inner query {{OrderBy}} "order by t.v2,t.pk3,t.v1" , but 
unfortunately it is not compiled out.


> Improve OrderPreservingTracker to support extracting partial ordering columns 
> for TupleProjectionPlan 
> --
>
> Key: PHOENIX-7352
> URL: https://issues.apache.org/jira/browse/PHOENIX-7352
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.2.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Major
>
> This is an improvement for  PHOENIX-5148: 
> Given a table
> {code:java}
>   create table test ( 
>pk1 varchar not null , 
>pk2 varchar not null, 
>pk3 varchar not null,
>v1 varchar, 
>v2 varchar, 
>CONSTRAINT TEST_PK PRIMARY KEY ( 
>  pk1,
>  pk2,
>  pk3 ))
> {code}
> PHOENIX-5148 optimized following sql to compile outer {{OrderBy}}  {{order by 
> v2,pk3}}:
> {code:java}
> select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
> t.v2,t.pk3,t.v1 limit 10) a order by v2,pk3
> {code}
> But if we , the outer {{OrderBy}} "order by v2,pk3" should be compiled out 
> because it matchs the inner query {{OrderBy}} "order by t.v2,t.pk3,t.v1" , 
> but unfortunately it is not compiled out.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (PHOENIX-7352) Improve OrderPreservingTracker to support extracting partial ordering columns for TupleProjectionPlan

[chenglei (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenglei updated PHOENIX-7352:
--
Description: 
This is an improvement for  PHOENIX-5148: 
Given a table
{code:java}
  create table test ( 
   pk1 varchar not null , 
   pk2 varchar not null, 
   pk3 varchar not null,
   v1 varchar, 
   v2 varchar, 
   CONSTRAINT TEST_PK PRIMARY KEY ( 
 pk1,
 pk2,
 pk3 ))
{code}
PHOENIX-5148 optimize following sql to compile outer {{OrderBy}}  {{order by 
v2,pk3}}:
{code:java}
select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
t.v2,t.pk3,t.v1 limit 10) a order by v2,pk3
{code}
But if we , the outer {{OrderBy}} "order by v2,pk3" should be compiled out 
because it matchs the inner query {{OrderBy}} "order by t.v2,t.pk3,t.v1" , but 
unfortunately it is not compiled out.

  was:This is an improvement for  PHOENIX-5148, 


> Improve OrderPreservingTracker to support extracting partial ordering columns 
> for TupleProjectionPlan 
> --
>
> Key: PHOENIX-7352
> URL: https://issues.apache.org/jira/browse/PHOENIX-7352
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.2.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Major
>
> This is an improvement for  PHOENIX-5148: 
> Given a table
> {code:java}
>   create table test ( 
>pk1 varchar not null , 
>pk2 varchar not null, 
>pk3 varchar not null,
>v1 varchar, 
>v2 varchar, 
>CONSTRAINT TEST_PK PRIMARY KEY ( 
>  pk1,
>  pk2,
>  pk3 ))
> {code}
> PHOENIX-5148 optimize following sql to compile outer {{OrderBy}}  {{order by 
> v2,pk3}}:
> {code:java}
> select v1 from (select v1,v2,pk3 from test t where pk1 = '6' order by 
> t.v2,t.pk3,t.v1 limit 10) a order by v2,pk3
> {code}
> But if we , the outer {{OrderBy}} "order by v2,pk3" should be compiled out 
> because it matchs the inner query {{OrderBy}} "order by t.v2,t.pk3,t.v1" , 
> but unfortunately it is not compiled out.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (PHOENIX-7352) Improve OrderPreservingTracker to support extracting partial ordering columns for TupleProjectionPlan

[chenglei (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenglei updated PHOENIX-7352:
--
Description: This is an improvement for  PHOENIX-5148, 

> Improve OrderPreservingTracker to support extracting partial ordering columns 
> for TupleProjectionPlan 
> --
>
> Key: PHOENIX-7352
> URL: https://issues.apache.org/jira/browse/PHOENIX-7352
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.2.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Major
>
> This is an improvement for  PHOENIX-5148, 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (PHOENIX-7352) Improve OrderPreservingTracker to support extracting partial ordering columns for TupleProjectionPlan

[chenglei (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenglei updated PHOENIX-7352:
--
Fix Version/s: (was: 5.2.1)

> Improve OrderPreservingTracker to support extracting partial ordering columns 
> for TupleProjectionPlan 
> --
>
> Key: PHOENIX-7352
> URL: https://issues.apache.org/jira/browse/PHOENIX-7352
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.2.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)