docs: refresh against the tree, and a full benchmark run that found a regression - #172
Merged
Conversation
… regression All three harnesses re-run at 7a9c9f7 on an idle box, and the documentation brought back in line with what the code now does. The run found something. Point lookup measured 1251.88 ms against 23.75 ms in the previous run, on the same machine and harness. It is not the lazy-decoding slot: an A/B across that merge on an unanalyzed table gives 16.42 ms before and 13.73 ms after. The difference between that probe and the harness is that the harness runs ANALYZE first, so the planner is choosing differently once statistics exist. Filed as #171, which also carries a second observation from the same investigation: ANALYZE ran for 23 minutes on a 250,000-row 8-column table and 40 minutes on a 6,000,000-row one in isolation, without reproducing inside the benchmark, which is why the issue says what is confirmed and what is not rather than naming a cause. The document presents that row as a bug report, not as a property of the design. Everything else moved the right way. DELETE of 1000 rows by id range is 14.7 ms against 22.8, a row-ordered UPDATE 14.28 against 20.78, both from #160 and #164. Two larger wins are recorded but not in the harness: index-driven access to a wide table went from 1,001,374 ms to 614 ms for 2,000 fetches on 41 columns when the lazy slot landed, and ANALYZE now collects statistics at all. Documentation. limitations.md said a point lookup must decode the whole row group and that bulk UPDATE is proportional to rows times group size; both were made false by #143 and #169 and now describe what happens. It gains what an import does about indexes and constraints, the deferrable-unique difference tracked as #168, and the ANALYZE cost with a pointer to #171. features.md gains column statistics and needed-columns fetch. ROADMAP's remaining list was "complete as of 2026-07-23" and is now the actual open set, ordered. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012uKWWwBDt5TWWS5DR2tzDb
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
1 participant
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.
All three harnesses re-run at
7a9c9f7on an idle box, and the documentation brought back in line with what the code does.The run found a regression
Same machine, same harness. It is not the lazy-decoding slot — an A/B across that merge on an unanalyzed 6,000,000-row table gives 16.42 ms before and 13.73 ms after. The difference between that probe and the harness is that the harness runs
ANALYZEbefore measuring, so the planner chooses differently once statistics exist, and chooses worse.Filed as #171, which also carries a second observation from the same investigation:
ANALYZEran 23 minutes on a 250,000-row 8-column table and 40 minutes on a 6,000,000-row one in isolation, and did not reproduce inside the benchmark, which completed all three harnesses in 26 minutes. The issue states what is confirmed and what is not rather than naming a cause. Autoanalyze runs the expensive half unprompted, which is why it matters beyond a benchmark row.The document presents that row as a bug report, not as a property of the design.
Everything else moved the right way
From #160's direct zone min/max comparison and #164's needed-columns fetch. Two larger wins are recorded in prose because the harness does not cover them: index-driven access to a wide table went from 1,001,374 ms to 614 ms for 2,000 fetches at 41 columns (#169, closing #157), and
ANALYZEcollects statistics at all (#159).Documentation
limitations.mdclaimed a point lookup must read and decode the whole row group, and that bulkUPDATEis proportional to rows times row group size. #143 and #169 made both false. It now describes what happens, and gains: what an import does about indexes and constraints, the deferrable-unique difference (#168), andANALYZEcost with a pointer to #171.features.mdgains column statistics and the needed-columns fetch.ROADMAP.md's remaining list said "complete as of 2026-07-23" and predated the audit and everything after it. It is now the actual open set, ordered by what is worth taking: bulk load throughput (#155), deferrable unique (#168), the ANALYZE pair (#171),reltuplesaccuracy.Verification
Every figure checked against the committed raw output in
bench/sample_output_all_2026_07_27.txt. Docs and captured output only, no code.