[
https://issues.apache.org/jira/browse/CALCITE-7680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18101908#comment-18101908
]
Julian Hyde commented on CALCITE-7680:
--------------------------------------
Leaning so heavily on metadata in a rule makes me uneasy. The metadata, after
all, bubbles up properties like maximum row-count in a generic way (so that you
can use it without knowing which subclass of RelNode you are looking at). But
the rules also bubble up that emptiness property. It seems like we're doing the
same thing two different ways – and the metadata way seems to be redundant.
> PruneEmptyRules should prune Sort when OFFSET is greater than or equal to max
> input rows
> ----------------------------------------------------------------------------------------
>
> Key: CALCITE-7680
> URL: https://issues.apache.org/jira/browse/CALCITE-7680
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.42.0
> Reporter: Yu Xu
> Assignee: Yu Xu
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.43.0
>
>
> PruneEmptyRules currently misses the case where the Sort has an OFFSET that
> is large enough to skip every row the input can produce.
> eg：
> {code:java}
> @Test void testEmptySortOffsetGreaterThanMaxRows() {
> // The input VALUES has at most 2 rows, so 'OFFSET 5' skips them all.
> final String sql = "select * from (values (1, 2), (3, 4)) as t (a, b)\n"
> + "order by a\n"
> + "offset 5 rows";
> sql(sql).check();
> } {code}
> plan is：
> {code:java}
> LogicalSort(sort0=[$0], dir0=[ASC], offset=[5])
> LogicalProject(A=[$0], B=[$1])
> LogicalValues(tuples=[[{ 1, 2 }, { 3, 4 }]]) {code}
> We could actually improve PruneEmptyRules to make the plan to：
> {code:java}
> LogicalValues(tuples=[[]]){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
