[
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 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}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
