[
https://issues.apache.org/jira/browse/CALCITE-5035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17503132#comment-17503132
]
Julian Hyde commented on CALCITE-5035:
--------------------------------------
Reviewing the PR:
* Nice, clean, well-commented code. Well done!
* The class name "{{SortProjectPullUpConstantsRule}}" is no longer appropriate
since the rule does not need to match a {{Project}}. Call it
{{SortRemoveConstantKeysRule}}, by analogy with
[ExchangeConstantKeysRule|https://github.com/apache/calcite/blob/bebe473fab2e242736614659ed6e5d04eeeb8bf5/core/src/main/java/org/apache/calcite/rel/rules/ExchangeRemoveConstantKeysRule.java].
Also change the constant field to {{CoreRules#SORT_REMOVE_CONSTANT_KEYS}}.
* Add '@see CoreRule#SORT_REMOVE_CONSTANT_KEYS' in the javadoc.
* The RelNode operand to the rule will cause the rule to fire on each input.
This is usually a bad thing, but is required in this case. Add a note
explaining why.
* The rule adds a {{Project}} with a literal. I don't think this is helpful. If
someone wants that behavior, they can use another rule.
* Add brief comments to each of the tests, e.g. that
{{testSortProjectPullUpConstantsNoFetchLimitAndSortEqualFields}} removes the
Sort (because there are no keys left),
{{testSortProjectPullUpConstantsWithFetchLimitAndSortMoreFields}} doesn't
remove the {{Sort}}, even though it is empty, because there is an offset.
* Don't add any more tests, but make sure one test has a LIMIT, and another has
a DESC, and another has a NULLS LAST.
> Define a rule of SortProjectPullUpConstantsRule to pull up constant's project
> under Sort
> ----------------------------------------------------------------------------------------
>
> Key: CALCITE-5035
> URL: https://issues.apache.org/jira/browse/CALCITE-5035
> Project: Calcite
> Issue Type: Improvement
> Reporter: Xurenhe
> Assignee: Xurenhe
> Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Define a rule to pull up constants project under Sort
> As we know, sorting by constant literal is meaningless.
> After the predicates' optimizing, the element of sort may be a constant
> literal, as below:
> {code:java}
> -- sql
> select pay_amount, pay_id, user_id
> from pay_tbl
> where pay_id = 1234
> group by pay_amount, pay_id, user_id
> order by pay_amount, pay_id, user_id
> -- rel tree
> -- after executing the rule of AggregateProjectPullUpConstantsRule
> LogicalSort(sort0=[$0], sort1=[$1], sort2=[$2], dir0=[ASC], dir1=[ASC],
> dir2=[ASC])
> LogicalProject(pay_amount=[$0], pay_id=[1234], user_id=[$1])
> LogicalAggregate(group=[{0, 1}])
> LogicalProject(pay_amount=[$1], user_id=[$3])
> LogicalFilter(condition=[=($0, 1234)])
> LogicalTableScan(table=[[default, pay_tbl]]){code}
> The field of pay_id in sort is a constant literal, it's meaningless for
> sort's operator.
> So, we could optimize it as below:
> {code:java}
> -- optimized rel tree
> LogicalProject(pay_amount=[$0], pay_id=[1234], user_id=[$1])
> LogicalSort(sort0=[$0], sort2=[$1], dir0=[ASC], dir2=[ASC])
> LogicalProject(pay_amount=[$0], user_id=[$1])
> LogicalAggregate(group=[{0, 1}])
> LogicalProject(pay_amount=[$1], user_id=[$3])
> LogicalFilter(condition=[=($0, 1234)])
> LogicalTableScan(table=[[default, pay_tbl]]) {code}
>
> Related
> discussion:https://lists.apache.org/thread/bq1gn6o7279f6563njhd5ln2j5178nwm
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
