Support generated columns in DELETE RETURNING optimization #9
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously, DELETE RETURNING would fall back to fetching columns by row ID when the table had generated columns. This was because generated columns cannot be scanned directly - they must be computed from their expressions. This change allows the optimization to work with generated columns by: 1. Scanning all physical columns and passing them through from the scan 2. Letting the RETURNING projection compute generated columns using their expressions (same approach as INSERT/UPDATE RETURNING) The comment in the fallback path is updated to reflect that generated columns are no longer a reason to use the fallback path.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR extends the DELETE RETURNING optimization from PR duckdb#20485 to support tables with generated columns.
Problem
Previously, DELETE RETURNING would fall back to the slower row-ID-fetch path when the table had generated columns because generated columns cannot be scanned directly from disk - they must be computed from their expressions.
Solution
Instead of falling back, we now:
This is the same approach already used by INSERT RETURNING and UPDATE RETURNING.
Changes
bind_delete.cpp: Removed theHasGeneratedColumns()check that was skipping the optimizationphysical_delete.cpp: Updated comment to reflect that generated columns are no longer a fallback reasonreturning_delete.test: Updated test commentsdelete_returning_3col_generated.benchmark: Updated descriptionTesting
All existing tests pass, including the tests for DELETE RETURNING with generated columns.