Refresh the roadmap's open list against the real issue state - #320
Merged
Conversation
The Remaining list was written on 2026-07-23 and listed two items that have since been closed, #168 and #171, as the next work to take. Anyone reading it for what to do next would have picked up finished work. Records the 2026-07-31 closures, and replaces the stale entries with what is actually open: selective-scan page reads (#310), bulk load throughput (#155) with the separate ingest path (#300) noted alongside it, and vectorized decompression and aggregation (#289). #310 is listed first and stated carefully: two causes are fixed and measured on a 20-group probe, and the 100M measurement that opened the issue has not been re-run against them, so the size of the remainder is unknown. Refs #310, #155, #300, #289. No issue is closed by this commit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011miCFRSatixeNRw3w5yNq8
ChronicallyJD
pushed a commit
that referenced
this pull request
Aug 1, 2026
The refresh in #320 rebuilt the open list from issue STATE. The follow-up commit on this branch fixed the #155 entry but repeated the same mistake on the entry it wrote to replace it. An audit of every entry against its issue thread, its pull requests and main found that all four were wrong, in three different ways. #289 was a copy of the issue body and gave no sign that work is in flight. The decompression half already merged (#307, 3.8 percent on q4 and 3.2 on q5) and the aggregation half is open as #321. The "about 4x behind TimescaleDB" line reads as the size of the prize for that work, but #321 measures 1.20x and 1.38x, and by its own account the larger lever is dictionary-coded grouping. The widest gap, q6 at 5.3x behind and 3.1x slower than heap, is the only shape where columnar loses to heap and nothing in flight touches it. #300 was framed as core COPY's per-field parse. #300's own profile refuted that before the entry was written: parse is about 21 percent, encode about 53 percent, so bypassing the parser cannot make columnar beat heap. The measured top lever is parallelism over the existing encoder with COPY unchanged, prototyped at 7.39x. IMPORT_THROUGHPUT_PLAN.md was cited as the reference and is the wrong pointer: it predates the #283 to #286 work and puts COPY under "Not in scope". reltuples is removed. It was fixed on 2026-07-28 by #189 and is now exact on every measured shape, and the cause the entry gave was explicitly disproven: it was a block-offset mismatch, not blocks holding no row-group data. The line was written about nine hours before the fix and survived two refreshes. #310 is no longer listed as work. Both causes are merged and it was re-measured at 100M, 273,212 buffers to 8,917. It stays open for a confirmation reading on the real dataset. #291 was open and absent from the list; added, with the note that its documentation half landed in #298. Also fixed, all verified: the "Deferred, not yet built" paragraph listed two things that have been on main since 2026-07-23; a cross-reference to "item 0" that #320's renumbering left dangling; six Done rows naming the extension schema as columnar rather than pgcolumnar, which a reader copying them would find does not exist; and a closed-since line with the wrong date and three omissions. Refs #289, #300, #291, #310. No issue is closed by this commit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011miCFRSatixeNRw3w5yNq8
ChronicallyJD
pushed a commit
that referenced
this pull request
Aug 2, 2026
The refresh in #320 rebuilt the open list from issue STATE and not from issue CONTENT. #155 was still open, so its original text was carried forward verbatim, including the "about 4.9x slower than heap" figure. That number was the problem statement from before the work, not the result: four encoder levers (#283 to #286, merged via #290) had already taken the 100M-row load from 783 s to 383 s and the gap to heap from about 4.9x to about 2.2x, with a byte-identical on-disk image. So the roadmap named finished work as the next thing to take, and quoted a measured figure that had been superseded. #155 itself was left open only because the resolution comment said "closing as resolved" without closing it; it is closed now, after verifying the four commits are on main. The entry becomes #300, which is the real remaining work: core COPY's per-field parse, paid identically by heap and TimescaleDB, and not reachable by another encoder change. Refs #155, #300. No issue is closed by this commit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011miCFRSatixeNRw3w5yNq8
ChronicallyJD
pushed a commit
that referenced
this pull request
Aug 2, 2026
The refresh in #320 rebuilt the open list from issue STATE. The follow-up commit on this branch fixed the #155 entry but repeated the same mistake on the entry it wrote to replace it. An audit of every entry against its issue thread, its pull requests and main found that all four were wrong, in three different ways. #289 was a copy of the issue body and gave no sign that work is in flight. The decompression half already merged (#307, 3.8 percent on q4 and 3.2 on q5) and the aggregation half is open as #321. The "about 4x behind TimescaleDB" line reads as the size of the prize for that work, but #321 measures 1.20x and 1.38x, and by its own account the larger lever is dictionary-coded grouping. The widest gap, q6 at 5.3x behind and 3.1x slower than heap, is the only shape where columnar loses to heap and nothing in flight touches it. #300 was framed as core COPY's per-field parse. #300's own profile refuted that before the entry was written: parse is about 21 percent, encode about 53 percent, so bypassing the parser cannot make columnar beat heap. The measured top lever is parallelism over the existing encoder with COPY unchanged, prototyped at 7.39x. IMPORT_THROUGHPUT_PLAN.md was cited as the reference and is the wrong pointer: it predates the #283 to #286 work and puts COPY under "Not in scope". reltuples is removed. It was fixed on 2026-07-28 by #189 and is now exact on every measured shape, and the cause the entry gave was explicitly disproven: it was a block-offset mismatch, not blocks holding no row-group data. The line was written about nine hours before the fix and survived two refreshes. #310 is no longer listed as work. Both causes are merged and it was re-measured at 100M, 273,212 buffers to 8,917. It stays open for a confirmation reading on the real dataset. #291 was open and absent from the list; added, with the note that its documentation half landed in #298. Also fixed, all verified: the "Deferred, not yet built" paragraph listed two things that have been on main since 2026-07-23; a cross-reference to "item 0" that #320's renumbering left dangling; six Done rows naming the extension schema as columnar rather than pgcolumnar, which a reader copying them would find does not exist; and a closed-since line with the wrong date and three omissions. Refs #289, #300, #291, #310. No issue is closed by this commit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011miCFRSatixeNRw3w5yNq8
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
2 participants
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.
The
## Remaininglist indesign/ROADMAP.mdwas written on 2026-07-23 andlisted two closed issues, #168 and #171, as the next work to take. Anyone reading
it to decide what to do next would have picked up finished work. The roadmap is
the project's stated source of truth, so a stale list there is worse than none.
What changed
Records the 2026-07-31 closures: #168, #171, #301, #311, #314, #254, and #282.
Replaces the stale entries with what is actually open, in value-to-effort order:
selective-query lever. Stated carefully: two causes are fixed and measured on
a 20-group probe, 9577 buffers to 1547, and the 100M measurement that opened
the issue has not been re-run against them. How much of the original 304,233
remains is unknown.
alongside rather than as its own entry, since they share a target.
reltuplesafterANALYZE, unchanged and still cosmetic.Note
No issue is closed by this commit, and it says so explicitly. Writing "does not
close #N" in a commit message closes #N: GitHub matches the keyword and ignores
the negation. That is how #310 came to be closed by the #315 commit, whose text
said the opposite. It has been reopened.