Skip to content

IGNITE-28389 SQL. Eliminate table scans with always_false predicate#7959

Open
AMashenkov wants to merge 12 commits intomainfrom
ignite-28389
Open

IGNITE-28389 SQL. Eliminate table scans with always_false predicate#7959
AMashenkov wants to merge 12 commits intomainfrom
ignite-28389

Conversation

@AMashenkov
Copy link
Copy Markdown
Member

Thank you for submitting the pull request.

To streamline the review process of the patch and ensure better code quality
we ask both an author and a reviewer to verify the following:

The Review Checklist

  • Formal criteria: TC status, codestyle, mandatory documentation. Also make sure to complete the following:
    - There is a single JIRA ticket related to the pull request.
    - The web-link to the pull request is attached to the JIRA ticket.
    - The JIRA ticket has the Patch Available state.
    - The description of the JIRA ticket explains WHAT was made, WHY and HOW.
    - The pull request title is treated as the final commit message. The following pattern must be used: IGNITE-XXXX Change summary where XXXX - number of JIRA issue.
  • Design: new code conforms with the design principles of the components it is added to.
  • Patch quality: patch cannot be split into smaller pieces, its size must be reasonable.
  • Code quality: code is clean and readable, necessary developer documentation is added if needed.
  • Tests code quality: test set covers positive/negative scenarios, happy/edge cases. Tests are effective in terms of execution time and resources.

Notes

@AMashenkov AMashenkov changed the title IGNITE-28389 SQL. Eliminate table scans with always_false predicate. IGNITE-28389 SQL. Eliminate table scans with always_false predicate Apr 8, 2026
@AMashenkov AMashenkov requested a review from korlov42 April 9, 2026 10:40
RelNode singleValue = call.builder().values(List.of(List.of(zeroLiteral)), singleRel.getRowType()).build();

RelTraitSet traits = singleRel.getTraitSet();
// propagate all traits (except convention) from the original singleRel
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we need this extra step of trait propagation? I think it's ok to emit logical node with default set of traits. Conversion to physical + trait propagation will do the job

SELECT /*+ DISABLE_RULE('NestedLoopJoinConverter', 'HashJoinConverter', 'CorrelatedNestedLoopJoin') */ *
FROM t1_n1n2n3 as t1, t1_n1n2n3 as t2
WHERE t1.id = t2.id and t1.id IN (1, 3) and t2.id IN (42, 44)
---
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's better to remove this test case completely because empty Values node doesn't bring much value for partition pruning test scenarios

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants