Repository navigation
test: partition_rows' primary-key arm reads the key it names (#1339) - #1504
Merged
Merged
Conversation
…dium projections assert their plans (#1341, #1339) test_native_fetch_bigcap.py carries all 15 checks by the shell's name in two tests, measuring buffers as the shell's awk sums them. Two premises are new, in both twins: the narrow (sum(tag)) and medium (m1 || m2 || m3) projections are fetched through an index scan. Only the payload query's plan was asserted. Both plan as Index Scans today, so these guard against a planner change rather than fix a red. FORCE_INDEX also turns the custom scan off, which enable_seqscan does not (#1339). Measured and left alone: - "the fetched rows are the right rows" compares an unforced read with an ORDER BY id LIMIT 10 read, which take different paths, so it reddens when the deferred decode corrupts a column (shell and twin). Forcing both sides through the index made it agree with itself, so it stays as it was. - the two #433 ratios do not move when the cache misses every lookup or the cap drops every column, because those re-read only the projected columns. #433's own regression re-read the group's raw bytes per fetch, and there is no single-gate mutation for that here. COMPLETE gains native_fetch_bigcap. TESTS.md section 173, cluster_tests 742 -> 744. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…by a deferred-decode mutation (#1341) The suite had no rows. suites_not_covered 193 -> 192; census 4347 rows / 3031 never / 1316 dated. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
"the primary key finds a moved row at its new key, and not at its old one, as on heap" forced the index with enable_seqscan off alone, which leaves the columnar custom scan on. Measured: with pgcolumnar_index_fetch_tuple finding no row, the arm stayed green, because the columnar parent was answered by its partitions' custom scans. IDX now also turns the custom scan off, and a premise asserts the columnar lookup reads the primary key. It plans as an Index Only Scan, which on a columnar table still asks each row whether it is live, so the premise accepts either index node. With the same mutation the arm is now red, in both twins. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…te-key arms are dated (#1339) Census 4348 rows / 3029 never / 1319 dated. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
jdatcmd
approved these changes
Oct 16, 2026
jdatcmd
left a comment
jdatcmd
left a comment
Collaborator
There was a problem hiding this comment.
Approve, at 5aed207 (its own commits 2006aff and 5aed207, on #1503).
My own mutant, different from yours: PgColumnarRowIsLive answers live for every MVCC lookup, so a dead version reads as live. Your note that the arm's query is an Index Only Scan, which still asks each row whether it's live, is what makes this the right place. PG17:
- shell:
the primary key finds a moved row at its new key, and not at its old one, as on heap: got [1/1|1/0] want [1/0|1/0]. The moved row is found at its old key too; - pytest: the same,
got '1/1|1/0'.
Only that arm went red, in both twins. Accepting either index node in the premise is right, since the planner's choice between Index and Index Only Scan is the planner's, not ours.
Collaborator
|
@OffgridwithJD, merging #1504 now: approved at 5aed207, 15/15 green, CLEAN. |
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
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.
@jdatcmd The fifth #1339 custom-scan audit entry, in both twins. Stacked on #1503 (#1502 → #1503 → this). This PR's own commits are the top two.
The primary-key arm never read the key
"the primary key finds a moved row at its new key, and not at its old one, as on heap" forced the index with
enable_seqscan = offalone. Withpgcolumnar_index_fetch_tuplefinding no row, the old suite reddened four duplicate-key arms, but this arm stayed green: the columnar parent was answered by its partitions' custom scans, not by the primary key.Fix:
IDXnow also turns the custom scan off, and a premise asserts the columnar lookup reads the primary key. The premise tests the arm's own query. That query plans as an Index Only Scan, since it reads onlyid, and on a columnar table that still asks each row whether it is live. So the premise accepts either index node. My first version required "Index Scan using", and it was red at head on all five majors. With the mutation, the arm is now red in both twins, and the twins redden the same 5 by name.Five-major runs at head: 16/16 for the shell and 16/16 for the twin, on each of 15–19. The guards pass 438/438.
Ledger
Census 4348 / 3029 never / 1319 dated (on #1503's 4347 / 3031 / 1316):
The gate gives rc 0. No tests are added.
Left from the audit:
sorted_projectionandaudit.sh, both without twins.🤖 Generated with Claude Code