Columnar partitions get neither the custom scan nor the index-fetch penalty: set_rel_pathlist_hook returns early for non-baserels

[ChronicallyJD]

Found while verifying the external validation report behind #433 and #434.

src/columnar_customscan.c:957 returns early when rel->reloptkind != RELOPT_BASEREL:

if (rel->reloptkind != RELOPT_BASEREL)
    return;                     /* ... */

A partition of a partitioned table is RELOPT_OTHER_MEMBER_REL, so for a columnar
partition reached through its parent we install neither the custom scan path nor the
index-fetch penalty (#355).

Measured

Same data, same index, one table partitioned and one not:

access	plan	time
through the parent	Index Scan	484 ms
the same partition addressed directly	Custom Scan (PgColumnarScan)	193 ms

Through the parent the cost is identical whether pgcolumnar.enable_index_fetch_penalty
is on or off, which is the direct evidence that the hook never ran. And
enable_indexscan=off on the parent falls back to a Seq Scan, not to our scan, because
our path was never offered.

Why it matters more than the 2.5x

Partitioning is the standard advice for large fact tables, which is the shape this project
targets. A user who partitions a columnar table silently loses:

• zone-map chunk-group skipping through the custom scan,
• vectorized aggregates,
• column projection at the scan,
• the index-fetch penalty that exists to stop the planner walking into Row groups above the 32 MB fetch-cache cap have a 100 percent miss rate: a full group re-read per fetched row #433.

The last one compounds: a partitioned blob-heavy table is exactly the case where #433's
100 percent fetch-cache miss is most expensive, and it is also the case where nothing
prices it.

Worth asking the reporter

Their ledger fixture may have been partitioned. If it was, this rather than #434 is the
main explanation for the plan they got, and their 33-minute query would be explained
entirely by the custom scan never being offered.

[ChronicallyJD]

One thing worth doing before anyone starts here: ask the external reporter whether their ledger table was partitioned.

If it was, this issue rather than #434 is the main explanation for the 33-minute query they saw, because the custom scan would never have been offered at all and enable_indexscan=off would have fallen back to a Seq Scan rather than to zone-map skipping. Their report says enable_indexscan=off gave them 76 ms, which suggests the custom scan was available and therefore that their table was not partitioned. But that is an inference from one number and they have the repro scripts.

Recording it so the question is asked before the two issues get merged into one.

[jdatcmd]

On whether the external report's 33-minute query was a partitioned table: there is nobody to ask, and I checked rather than assuming there was.

The "reporter" is a document — an external validation report dated 2026-08-05, two EC2 architectures, PGDG 18.4 — not a participant on any thread here. #433 and #434 are both authored internally and both closed. The report is referenced in the continuity notes but is not in the repository, so its schema is not recoverable from anything we hold.

So the attribution question cannot be settled, and I do not think it should be forced:

• Row groups above the 32 MB fetch-cache cap have a 100 percent miss rate: a full group re-read per fetched row #433 identified a mechanism that already accounts for the shape: row groups above the 32 MB fetch-cache cap missing 100% of the time, ~25 ms/row, which reaches 33 minutes at 100k rows without partitioning being involved at all. It was closed on that mechanism.
• Index-fetch penalty collapses to zero on a correlated index, and the custom scan is priced as if zone maps did not exist #434 was closed on a measurement, not on its original diagnosis — planner_choice_quality.sh from Assert the planner's chosen plan is not far worse than one it declined (#434) #444 failed on main before Read a fetched column's own chunk, not the whole row group (#433) #459/Price the columnar scan for what the zone maps let it skip (#434 cause 2) #460 and passes after. (Worth noting the continuity notes still say Index-fetch penalty collapses to zero on a correlated index, and the custom scan is priced as if zone maps did not exist #434 "must not be closed on the original diagnosis"; that line predates the fix and is stale, which I confirmed before raising it as a discrepancy.)
• Columnar partitions get neither the custom scan nor the index-fetch penalty: set_rel_pathlist_hook returns early for non-baserels #436 stands on its own evidence and does not need the report: 53x on a fixture where partitioning is the only variable, measured here, reproducible.

The honest outcome is that neither issue claims the other's report. A partitioned ledger table would make #436 a plausible contributor to those 33 minutes, but "plausible contributor" is not attribution, and #433's mechanism is sufficient on its own. Writing #436 into the report's history without the schema would be exactly the error made twice on #445 — reasoning from a symptom to an owner, when the specifics were what decided it and were never read.

If the report ever surfaces with its DDL, this is a one-line question to answer. Until then #436 is merged on its measurement and the 33 minutes stays with #433.