webgrip/unfold
5
0
Fork 0
Code Issues 1 Pull requests 3 Projects Releases 54 Packages 8 Wiki Activity Actions 2

test(ploeg): make the claimable-index plan test independent of statistics #182

Merged
ryangr0 merged 1 commit from ryangr0/ploeg-claimable-index-deterministic into development 2026-10-03 12:19:57 +00:00 AGit
Conversation 0 Commits 1 Files changed 2 +25 -15
ryangr0 commented 2026-10-03 12:18:12 +00:00
Owner
Copy link

TestClaim_StillUsesClaimableIndex asked the planner for its preferred plan
on a work_items table holding one seeded row. Whether Postgres preferred
work_items_claimable or a sequential scan depended on the table's
statistics, which autoanalyze refreshes on its own schedule after the other
store tests insert and delete rows. Under parallel load the refresh landed
before the EXPLAIN often enough to flake: with accurate statistics for a
one-row table a sequential scan is genuinely cheaper.

The test now runs the EXPLAIN in a transaction with SET LOCAL
enable_seqscan = off. That removes the statistics dependency and asks the
question the test exists for: can the claim use the partial index at all?
If the query stops implying the index predicate (state = 'queued'), the
planner falls back to another index and the test fails.

The test also EXPLAINed a hand-copied query that had already drifted from
the real one (it lacked NOT operator_owned). The candidate subselect is now
the nextClaimableQuery constant, used by ClaimWithin and EXPLAINed by the
test, so a change to the claim query is what the test checks.

The test also EXPLAINed a hand-copied query that had drifted from the real claim (missing NOT operator_owned); it now EXPLAINs the same constant ClaimWithin uses, under SET LOCAL enable_seqscan = off. Proven to fail when the predicate stops matching; 50/50 passes under a parallel full suite.

Verified with mise run verify on the pinned toolchain (all gates passed).

Ticket: https://vikunja.webgrip.dev/tasks/1824

🤖 Generated with Claude Code

TestClaim_StillUsesClaimableIndex asked the planner for its preferred plan on a work_items table holding one seeded row. Whether Postgres preferred work_items_claimable or a sequential scan depended on the table's statistics, which autoanalyze refreshes on its own schedule after the other store tests insert and delete rows. Under parallel load the refresh landed before the EXPLAIN often enough to flake: with accurate statistics for a one-row table a sequential scan is genuinely cheaper. The test now runs the EXPLAIN in a transaction with SET LOCAL enable_seqscan = off. That removes the statistics dependency and asks the question the test exists for: can the claim use the partial index at all? If the query stops implying the index predicate (state = 'queued'), the planner falls back to another index and the test fails. The test also EXPLAINed a hand-copied query that had already drifted from the real one (it lacked NOT operator_owned). The candidate subselect is now the nextClaimableQuery constant, used by ClaimWithin and EXPLAINed by the test, so a change to the claim query is what the test checks. The test also EXPLAINed a hand-copied query that had drifted from the real claim (missing NOT operator_owned); it now EXPLAINs the same constant ClaimWithin uses, under SET LOCAL enable_seqscan = off. Proven to fail when the predicate stops matching; 50/50 passes under a parallel full suite. Verified with `mise run verify` on the pinned toolchain (all gates passed). Ticket: https://vikunja.webgrip.dev/tasks/1824 🤖 Generated with [Claude Code](https://claude.com/claude-code)
test(ploeg): make the claimable-index plan test independent of statistics
All checks were successful
[Workflow] On Pull Request / release-policy (pull_request) Successful in 38s
Details
[Workflow] On Pull Request / checks (pull_request) Successful in 11m2s
Details
[Workflow] On Pull Request / warnings (pull_request) Successful in 0s
Details
0d70c43441
 
TestClaim_StillUsesClaimableIndex asked the planner for its preferred plan
on a work_items table holding one seeded row. Whether Postgres preferred
work_items_claimable or a sequential scan depended on the table's
statistics, which autoanalyze refreshes on its own schedule after the other
store tests insert and delete rows. Under parallel load the refresh landed
before the EXPLAIN often enough to flake: with accurate statistics for a
one-row table a sequential scan is genuinely cheaper.

The test now runs the EXPLAIN in a transaction with SET LOCAL
enable_seqscan = off. That removes the statistics dependency and asks the
question the test exists for: can the claim use the partial index at all?
If the query stops implying the index predicate (state = 'queued'), the
planner falls back to another index and the test fails.

The test also EXPLAINed a hand-copied query that had already drifted from
the real one (it lacked NOT operator_owned). The candidate subselect is now
the nextClaimableQuery constant, used by ClaimWithin and EXPLAINed by the
test, so a change to the claim query is what the test checks.

VIK-1824

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
ryangr0 merged commit cb8267d9ca into development 2026-10-03 12:19:57 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
webgrip/unfold!182
No description provided.