Record the projection, vectorized aggregate and planner wave in the changelog (#367) - #372
Conversation
) The changelog stopped at #330. Everything from #321 onward was unrecorded: column projection, all four vectorized aggregate settings, the index-fetch cost model, and the fetch cache work. For an alpha that is the wrong gap to have, since three of those are user-visible settings and one of them (#339 column projection, and #355 index-fetch penalty) is on by default. Added: column projection with its measured gains and the honest note that grouped shapes gain far less than the headline 6.9x; the three vectorized aggregate GUCs with why they remain off by default, pointing at #369; and enable_index_fetch_penalty with what it prices and how to turn it off. Changed: the fetch cache going from a cliff to a proportional overflow (#353, #359), the penalty ordering fix and the two defects found with it (#362), the grouped aggregate costing (#349), and the fold's scan-key pushdown (#349). No em or en dashes, per test/docs_style.sh. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ChronicallyJD
left a comment
ChronicallyJD
left a comment
There was a problem hiding this comment.
Reviewed. The entries are accurate, the style matches, and putting the two
default-on changes at the top is the right call — an alpha that changed behaviour for
every install without a record would be the worst kind of quiet.
Two corrections, both on numbers I produced, so the error is mine to flag.
1. The 224-second figure attributes #361's improvement to #362
The planner chose an index scan it priced at 13,954,742 over a columnar path it
priced at 589,348, running 224 seconds where the columnar path runs 4.7.
Those are my numbers and they are real, but 224 s was measured before #361 merged.
#361 is in this same release, and it cut that plan by 12x on its own. Measured on the
100M fixture:
| build | plan chosen | time |
|---|---|---|
1d90693 (pre-#361) |
Index Scan | 224,055 ms |
cd06471 (with #361, without #362's fix) |
Index Scan | 18,439 ms |
| with the #362 fix | Parallel Custom Scan | 4,903 ms |
A reader of the 1.0-alpha changelog is on a build that has both. What they get from
the penalty-ordering fix is 18.4 s → 4.9 s, 3.8x — not 224 s → 4.7 s. Quoting the
pre-#361 number in an entry for a release containing #361 credits one fix with the
other's win.
Suggested: "running 18.4 seconds where the columnar path runs 4.9" and, if you want
the drama, a clause noting the same plan cost 224 s before #359's cache fix landed in
this release. Both numbers are honest; the pairing is what misleads.
I made the same mistake on #365's PR body and corrected it there, so this is me
catching my own framing a second time rather than yours.
2. "costs the overflow fraction rather than everything" has a measured limit
True on the shapes #359 targets. It does not hold on wide varlena tables, and #364 has
the numbers: 150,000 rows x 60 text columns gives 1.14x (127,699 ms against
145,132 ms), because the retained position indexes alone exceed the cap and nearly
every column overflows anyway.
That is not an argument against the entry — the change is a clear improvement — but
"rather than everything" reads as a general property and it is a property of the
common case. You gave #369 exactly this treatment in the vectorization entry ("these
remain off by default because plan selection is not settled"), and this deserves the
same sentence: something like "on tables of many wide varlena columns the retained
position indexes can exceed the cap on their own, and the gain is much smaller
(#364)."
#370 corrects the design doc and the code comment for the same claim; the changelog is
the third place it appears.
Nothing else
The #349 costing entry, the scan-key pushdown entry and the #369 caveat all match what
I measured independently. The projection entry giving the grouped numbers next to the
6.9x headline is the right instinct — the 6.9x is the number that would otherwise get
quoted alone.
Happy to approve once the 224 s pairing is addressed. I am not blocking on point 2 if
you would rather keep the entry short, though I think it is worth the sentence.
2 participants
What
Part of the 1.0-alpha checklist (#367), the CHANGELOG item I took.
The changelog stopped at #330. Everything from #321 onward was unrecorded:
enable_index_fetch_penalty(#355)enable_ungrouped_vector_agg(#337)enable_parallel_vector_agg(#343, #346, #366)enable_group_vectorization(#321),groupagg_max_groupsTwo of those are on by default, so an alpha shipping without them documented
would change behaviour for every install with no record of it.
What the entries say
Written in the existing style: prose, issue references, measured numbers rather
than adjectives.
The projection entry gives the 6.9x headline and the grouped-shape numbers
(1.24x, 1.13x, 3.13x), because the 6.9x does not generalise and #349's thread is
the record of someone generalising it.
The vectorized aggregate entry says plainly why they are still off by default:
plan selection is not settled, and an expression grouping key can decline the
parallel path on a group estimate that is 25-42x wrong (#369). That is a known
limitation a reader should get from the changelog rather than the tracker.
Not included
VERSIONstill reads1.0-devand[Unreleased]is still[Unreleased]. I amnot cutting the version while the checklist has open items (benchmarks re-measure,
docs accuracy pass, #363, #364). That is a separate commit once #367 clears.
Verification
test/docs_style.shchecks CHANGELOG.md for em and en dashes; the file has zero.No code changes, so no matrix run is implied by this PR. The full five-major
matrix is running separately against
488a2c0and will be reported on #367.🤖 Generated with Claude Code