Rebuild the roadmap against what the issue threads actually say

[ChronicallyJD]

Started as a one-entry fix for #155. An audit of the whole open list found that
all four entries were wrong, including the replacement entry this branch had
just written. Rewritten accordingly.

The failure mode

#320 rebuilt the list from issue state. An issue being open does not mean its
text is still true. Checking state and not content produced three distinct errors:

entry	what was wrong
#310	said the 100M measurement "has not been re-run"; it had been, 11 hours earlier, 273,212 buffers to 8,917
#300	framed the remaining work as core COPY's parse; #300's own profile had already refuted that
#289	a copy of the issue body, no sign that #307 merged or that #321 is open
reltuples	fixed on 2026-07-28 by #189, with a cause that was explicitly disproven

What each entry says now

#289, first. The only item with work in flight. Decompression half merged
(#307). Aggregation half open as #321, measured at 1.20x/1.38x, not merged: review
reproduced two wrong-answer defects and a vacuous test section. The entry now says
plainly that 1.20x is not the ~4x prize, that the larger lever is dictionary-coded
grouping, and that q6, the widest gap at 5.3x behind TimescaleDB and the only shape
where columnar loses to heap, is untouched by anything in flight.

#300, second. Bulk load is done (#155). The remaining lever is parallel ingest,
prototyped at 7.39x on eight writers with core COPY unchanged, not a parse
bypass: parse is ~21% of the load, encode ~53%. IMPORT_THROUGHPUT_PLAN.md is
flagged as the wrong reference, since it predates #283 to #286 and puts COPY under
"Not in scope".

#291, third, newly added. Its documentation half landed in #298; the code
comments remain, and no gate covers them.

#310 is moved out of the list entirely, under "not work, but still open", with
the measured before/after and the one thing actually outstanding: a confirmation
reading on the real dataset.

reltuples is removed. Fixed and now exact.

Structural fixes, all verified

• "Deferred (documented, not yet built)" listed end-truncation and reclaim
  split/coalesce; both have been on main since 2026-07-23 (pgcolumnar.truncate
  exists; Phase F reclaim: free-space splitting and coalescing #90 merged). Corrected, with the one genuinely outstanding item kept.
• A cross-reference to "item 0 above" that Refresh the roadmap's open list against the real issue state #320's renumbering left dangling.
• Six Done rows named the extension schema columnar. instead of pgcolumnar..
  A reader copying columnar.export_arrow gets "function does not exist".
• The closed-since line had the wrong date and omitted The column cache is dead code: its only entry point has no callers, and three tests pass because of it #303 and Building PostgreSQL 19 from source: -std=gnu23 reaches PGXS but not every compiler accepts it #294.

Docs-only, no code changes, no matrix run. test/docs_style.sh passes.

Every claim above was checked against the issue thread, the PR state, or main.

[ChronicallyJD]

Review: accurate, and the right failure-mode fix

I fact-checked every entry I have primary knowledge of against my own measurements and the merged state; they are correct:

• Vectorized decompression + aggregation for full-scan aggregates (~4× behind TimescaleDB) #289 / Grouped vectorized aggregate (#289) #321 — the two wrong-answer defects (sum(real) returns 0; gating WHERE clauses dropped) and the vacuous test section are real and reproduced; I confirmed them against the branch. 1.20×/1.38× are my A/B numbers, and the framing that this is the foundation, not the ~4× (dictionary-coded grouping is the lever), matches Grouped vectorized aggregate (#289) #321's own body. Fixing all three now.
• Explore a faster bulk-ingest path that bypasses core COPY's per-field parse (post-#155 load gap) #300 — 21% parse / 53% encode / 27% pipeline, and the 85.2s→11.5s (7.39×, plateau at 8 physical cores) prototype are exactly my measurements. Flagging IMPORT_THROUGHPUT_PLAN.md as the wrong reference (predates Skip the FSST table build when the dictionary wins: -22% text bulk load (#155) #283–Batch the Gorilla bit writer: -13% more, now faster than TimescaleDB on load (#155) #286, puts COPY out of scope) is correct — the live work is on the Explore a faster bulk-ingest path that bypasses core COPY's per-field parse (post-#155 load gap) #300 thread / PARALLEL_COPY_PLAN.md (draft Parallel bulk ingest: pgcolumnar.parallel_copy (#300) #323).
• Chunk-group skipping avoids decode but not page reads: skipping to 1 of 667 groups still faults ~the whole table #310 — the 273,212→8,917 buffer / 34× re-measurement and the "one filter is 256 kB, catalog 3.5 GB" characterization match the thread; "open only for a confirmation reading on real TSBS" is the right remaining scope.
• Done-table + "now built" — spot-checked: pgcolumnar.truncate/enable_end_truncation exist, the columnar.*→pgcolumnar.* renames are correct, Bulk load is 4.9x slower than heap, and import inherits it #155 merged via Tests for the #155 encoding rewrites (carries the stack) #290.

The core point is right and worth stating: #320 rebuilt the list from issue state, and open ≠ still-true. Checking content caught three stale entries plus the one this branch had just written — a good catch on itself. No inaccuracies found on my read.

One small thing (non-blocking): the #90 commit for reclaim split/coalesce — I couldn't confirm the term by grep in columnar_storage.c; worth a second's check that the cited commit is the right hash, since the whole point here is precision.

[ChronicallyJD]

Your approval predates the current content, so please do not treat it as standing.

• Your review: 2026-08-01T17:57:43Z
• My last commit: 2026-08-01T18:09:05Z

What you fact-checked was the revision that an audit then found two blockers in,
and both were in text I had written to correct earlier errors:

1. The paragraph correcting two "listed as not built, actually built" items called
   the F1 delete-vector rename the one still outstanding. It is built too: the
   catalog is named pgcolumnar.delete_vector today. The correction committed the
   error it was correcting.
2. "q6 is the only shape where columnar loses to heap" is false. Vectorized decompression + aggregation for full-scan aggregates (~4× behind TimescaleDB) #289's own table
   shows q8 loses as well, 21,608 ms against heap's 15,315 ms. That sentence was
   load-bearing, since it was the justification for singling q6 out.

Also wrong in what you approved: "34x" did not follow from the two figures in its
own sentence (1252/39 is 32.1); #317 was credited with closing #314, which was
closed an hour before #317 existed; and the file claimed a PostgreSQL 13-19 matrix
in three places when it is 15-19.

I am not raising this to relitigate the review. I am raising it because it is
evidence for the change I then made. You wrote that you fact-checked every entry you
had priors on, and I believe you did; two blockers still survived. Four revisions of
this file have now been wrong, three of them in the correction. That is not four
careless people, it is a file whose entries restate measurements that live somewhere
else, where every restated number is a number that goes stale the moment its issue
moves.

So the current revision carries no measurements in the open list at all. Each
entry says what the work is, what is in flight, and which issue holds the figures.
Claims that cannot drift stay; claims that can are now pointers. That is the actual
proposal, and it is worth a fresh look precisely because it is a different shape
from what you approved.

Concretely, worth re-checking: the three entries no longer assert any number, the
"formerly deferred" paragraph now says all three are built with the schema name as
evidence, and 13-19 is corrected to 15-19 in all three places.

[ChronicallyJD]

Re-reviewed the current revision (fresh — not standing on the 17:57 approval)

You were right to pull the earlier approval; I re-checked this revision against the merged state, and the corrections hold:

• 15-19 now everywhere the matrix is cited (header, "Future directions", "PostgreSQL 18/19 adoption"); no 13-19 remains.
• pgcolumnar. prefix throughout the Done table (was columnar.).
• The open list carries no measurements — each item points to its issue. After four revisions drifted on restated numbers, this is the right shape.
• q6 and q8 are both named as the shapes that lose to heap; the "q6 is the only one" claim is gone.
• The F1 delete-vector rename is correctly listed as built, with pgcolumnar.delete_vector as schema evidence.
• Bulk load is 4.9x slower than heap, and import inherits it #155 moved to Closed; Explore a faster bulk-ingest path that bypasses core COPY's per-field parse (post-#155 load gap) #300 framed as the remaining parallelism lever, not a COPY-parser bypass.

One status has already drifted since the 18:09 commit — the exact failure mode this rewrite exists to prevent:

• Item 1 says Grouped vectorized aggregate (#289) #321 "is not merged" and "review reproduced two wrong-answer defects and a vacuous test section." Grouped vectorized aggregate (#289) #321 merged at 2026-08-01T22:31:39Z (the review findings were fixed first, and an adversarial pass caught four more). That restated status is precisely what this file's thesis says should be a pointer, not a claim. Suggest dropping the merge-status/defect sentence and letting Grouped vectorized aggregate (#289) #321 hold its own state.

Fix that one line and it's good to land — everything else checks out.