[
https://issues.apache.org/jira/browse/CALCITE-6335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17943733#comment-17943733
]
Zhen Chen edited comment on CALCITE-6335 at 4/12/25 4:10 AM:
-------------------------------------------------------------
I tried to write a demo. It is implemented through the {{!set rules}} command.
In it, rules are used to indicate the rules to be added or removed, "-"
indicates the rules to be removed, and "+" indicates the rules to be added. It
can contain {{CoreRules/EnumerableRules/...}} . The logic of other {{!xxx}}
commands remains unchanged. After executing the specified rules, {{!set
reset-rules ""}} is used to restore to the default rules. Is this design
reasonable? Can you give me some suggestions? Demo is here
[https://github.com/apache/calcite/pull/4301.]
iq file like this:
[https://github.com/apache/calcite/pull/4301/files#diff-c1fe2cc2a6dad325546d88eaae430d6715818bcac1f6988760801d0f967fbbfb]
{code:java}
# test.iq - Join query tests!set outputformat mysql
!set rules
"-CoreRules.INTERSECT_TO_DISTINCT,-EnumerableRules.ENUMERABLE_INTERSECT_RULE,+CoreRules.INTERSECT_TO_SEMI_JOIN"
# Test one
with t (i) as (values (0), (1))
select * from t as t1
intersect
select * from t as t2 where t2.i > 0;
+---+
| I |
+---+
| 1 |
+---+
(1 row)!ok
EnumerableNestedLoopJoin(condition=[IS NOT DISTINCT FROM($0, $1)],
joinType=[semi])
EnumerableValues(tuples=[[{ 0 }, { 1 }]])
EnumerableCalc(expr#0=[{inputs}], expr#1=[0], expr#2=[>($t0, $t1)],
EXPR$0=[$t0], $condition=[$t2])
EnumerableValues(tuples=[[{ 0 }, { 1 }]])
!plan
!set reset-rules ""
# Test two
with t (i) as (values (0), (1))
select * from t as t1
intersect
select * from t as t2 where t2.i > 0;
+---+
| I |
+---+
| 1 |
+---+
(1 row)
!ok
EnumerableIntersect(all=[false])
EnumerableValues(tuples=[[{ 0 }, { 1 }]])
EnumerableCalc(expr#0=[{inputs}], expr#1=[0], expr#2=[>($t0, $t1)],
EXPR$0=[$t0], $condition=[$t2])
EnumerableValues(tuples=[[{ 0 }, { 1 }]])
!plan
# End test.iq {code}
was (Author: jensen):
I tried to write a demo. It is implemented through the {{!set rules}} command.
In it, rules are used to indicate the rules to be added or removed, "-"
indicates the rules to be removed, and "+" indicates the rules to be added. It
can contain {{CoreRules/EnumerableRules/...}} . The logic of other {{!xxx}}
commands remains unchanged. After executing the specified rules, {{!set
reset-rules ""}} is used to restore to the default rules. Is this design
reasonable? Can you give me some suggestions? Demo is here
[https://github.com/apache/calcite/pull/4301.]
iq file like this:
[https://github.com/apache/calcite/pull/4301/files#diff-c1fe2cc2a6dad325546d88eaae430d6715818bcac1f6988760801d0f967fbbfb]
{code:java}
# test.iq - Join query tests!set outputformat mysql
!set rules
"-CoreRules.INTERSECT_TO_DISTINCT,-EnumerableRules.ENUMERABLE_INTERSECT_RULE,+CoreRules.INTERSECT_TO_SEMI_JOIN"#
Test one
with t (i) as (values (0), (1))
select * from t as t1
intersect
select * from t as t2 where t2.i > 0;
+---+
| I |
+---+
| 1 |
+---+
(1 row)!okEnumerableNestedLoopJoin(condition=[IS NOT DISTINCT FROM($0, $1)],
joinType=[semi])
EnumerableValues(tuples=[[{ 0 }, { 1 }]])
EnumerableCalc(expr#0=[{inputs}], expr#1=[0], expr#2=[>($t0, $t1)],
EXPR$0=[$t0], $condition=[$t2])
EnumerableValues(tuples=[[{ 0 }, { 1 }]])
!plan
!set reset-rules ""# Test two
with t (i) as (values (0), (1))
select * from t as t1
intersect
select * from t as t2 where t2.i > 0;
+---+
| I |
+---+
| 1 |
+---+
(1 row)!okEnumerableIntersect(all=[false])
EnumerableValues(tuples=[[{ 0 }, { 1 }]])
EnumerableCalc(expr#0=[{inputs}], expr#1=[0], expr#2=[>($t0, $t1)],
EXPR$0=[$t0], $condition=[$t2])
EnumerableValues(tuples=[[{ 0 }, { 1 }]])
!plan# End test.iq {code}
> Quidem tests should allow specifying optimization passes to apply to programs
> -----------------------------------------------------------------------------
>
> Key: CALCITE-6335
> URL: https://issues.apache.org/jira/browse/CALCITE-6335
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.36.0
> Reporter: Mihai Budiu
> Priority: Minor
> Labels: pull-request-available
>
> This facility would make it much easier to test various optimization passes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
