Skip to content

ORCA: fallback the locking clause #1052

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

jiaqizho
Copy link
Contributor

@jiaqizho jiaqizho commented Apr 17, 2025

Fixes #1031

What does this PR do?

If the current GDD is closed and there is a forupdate statement, ORCA and planner does not need to generate a LockRows operator, expect the table is foreign table. However, if the current GDD is enabled, ORCA will generate a plan without the LockRows operator, which is a wrong plan.

Supporting locking clauses in ORCA is a very difficult thing. Because ORCA does not fill root->glob->paramExecTypes in every operator, even if ORCA generates the LockRows operator, it may not working in the executor. For details, please refer to the EPQ(evalPlanQual) mechanism.

Also I don't think ORCA should consider supporting locking clause. ORCA is an optimizer that is more biased towards OLAP scenarios. Support the EPQ mechanism will make ORCA more complex and more difficult to expand.

Type of Change

  • Bug fix (non-breaking change)
  • New feature (non-breaking change)
  • Breaking change (fix or feature with breaking changes)
  • Documentation update

Breaking Changes

Test Plan

  • Unit tests added/updated
  • Integration tests added/updated
  • Passed make installcheck
  • Passed make -C src/test installcheck-cbdb-parallel

Impact

Performance:

User-facing changes:

Dependencies:

Checklist

Additional Context

CI Skip Instructions


@jiaqizho jiaqizho force-pushed the orca-support-select-update branch from 542dc9d to 44708c6 Compare April 18, 2025 03:13
If the current GDD is closed and there is a `forupdate` statement,
ORCA and planner does not need to generate a `LockRows` operator,
expect the table is foreign table. However, if the current GDD is
enabled, ORCA will generate a plan without the `LockRows` operator,
which is a wrong plan.

Supporting locking clauses in ORCA is a very difficult thing. Because
ORCA does not fill `root->glob->paramExecTypes` in every operator,
even if ORCA generates the `LockRows` operator, it may not working
in the executor. For details, please refer to the EPQ(evalPlanQual)
mechanism.

Also I don't think ORCA should consider supporting locking clause.
ORCA is an optimizer that is more biased towards OLAP scenarios.
Support the EPQ mechanism will make ORCA more complex and more
difficult to expand.
@jiaqizho jiaqizho force-pushed the orca-support-select-update branch from 44708c6 to 0873375 Compare May 7, 2025 01:32
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.

[Bug] ORCA generates wrong plan for select-for-update statement.
3 participants