The Gather cost is charged per row and is blind to tuple width, which holds nine of eleven measured cells and an extension cannot change it

[jdatcmd]

docs/limitations.md, "Parallel scans", records this as known and unfixed:

On a narrow but selective scan the planner still prefers the serial plan even where the
parallel one is faster. Measured: a three-column selective scan of a four-million-row table
ran up to 2.5x faster in parallel, and the planner chose serial anyway.

The cause is the cost of the Gather node. The planner prices each row passed from a worker
to the leader at parallel_tuple_cost, the same rate it uses for a heap scan. A columnar
scan ships fewer, already-decoded rows, so that rate overstates its Gather cost. On the
shape above the Gather cost reached almost the whole cost of the serial scan. The serial
plan won on cost while losing on the clock.

So this is a costing asymmetry with a measured number attached, not a missing feature: the
parallel path exists and is built, and on a wide projection it is already chosen.

Relationship to #369

#369 (closed) is the same class one node higher: the grouped parallel aggregate arm lost to
the serial node because the Finalize was priced off estimate_num_groups on an expression
key. Worth reading before starting, because the shape of the fix and the traps in measuring
it will be similar. This issue is about the scan, not the grouped aggregate.

The care this needs

The doc is explicit that the default rate is conservative for any row-returning parallel
scan, not only a columnar one, and that a heap scan on the same shape also flipped. So the
fix must not be "discount our Gather until we win": it has to be defensible as pricing what
a columnar scan actually ships, and it needs a control on a shape where the serial plan is
genuinely right, or it will just move the error to the other side.

Per the house rule, calibrate the threshold in the context the check runs in, and assert the
chosen plan on both arms rather than the runtime alone.

[jdatcmd]

Measured. The phenomenon is real. The stated cause is not.

Nothing below inherits the published 2.5x. docs/limitations.md names only "a three-column
selective scan of a four-million-row table": no selectivity, no column types, no fixture, so
it is not reproducible from the doc.

Fixture. 4,000,000 rows, 14 columns (8 int of varying cardinality, 4 md5 text, numeric,
float8), all hashint4-derived so nothing is trivially compressible. Columnar 383 MB against
a heap twin at 845 MB. PG 17. A first fixture that made every column compressible produced
2.6 MB against 355 MB, 133x, and was discarded: a scan that cheap exaggerates any Gather-cost
effect by construction.

Knob discipline. parallel_setup_cost and min_parallel_table_scan_size are never used
to decide what the planner chooses; parallel_tuple_cost is lowered only to force a plan
whose execution is then timed. An early sweep of mine set both to zero "to make the parallel
path visible" and the columnar scan then chose Gather at three of four selectivities, which
would have been reported as the baseline. Every plan choice below is at defaults with only
max_parallel_workers_per_gather raised.

1. The shape, found by sweeping rather than assumed

30 cells, 5 projection widths x 6 selectivities, plan choice only (free). The planner chooses
Gather on the wide/low-row cells and serial on 11 cells, all of them narrow projection
or high row count. "Selective" in the doc turns out to mean selective in columns: fewer
columns means less decode, the serial columnar scan gets cheaper, and a fixed per-row Gather
charge then dominates it.

2. On all 11 serial-chosen cells, the declined parallel plan is faster

EXPLAIN (ANALYZE, TIMING OFF), 7 interleaved reps per arm, both arm orders checked on a
subset (2.63x and 2.73x, so order does not decide it).

rows out	projection	serial med / min	parallel med / min	med	min
999,987	sel	162.7 / 152.2	66.0 / 52.7	2.46x	2.89x
999,987	sel, a	166.0 / 164.7	70.0 / 62.1	2.37x	2.65x
999,987	sel, a, b	185.7 / 177.5	86.8 / 68.4	2.14x	2.60x
2,000,197	sel	177.1 / 170.9	89.8 / 73.8	1.97x	2.32x
2,000,197	sel, a	213.3 / 206.2	96.0 / 84.3	2.22x	2.45x
2,000,197	sel, a, b	224.1 / 219.2	106.9 / 98.7	2.10x	2.22x
2,000,197	8 columns	278.2 / 271.3	151.6 / 130.6	1.83x	2.08x
2,000,197	*	1542.2 / 1518.9	597.7 / 529.3	2.58x	2.87x
3,000,052	sel	207.9 / 205.1	101.1 / 89.4	2.06x	2.29x
3,000,052	sel, a	269.3 / 263.5	123.7 / 110.9	2.18x	2.38x
3,000,052	sel, a, b	296.7 / 285.2	136.4 / 122.3	2.17x	2.33x

The finding is the non-overlap, not the ratio. Serial min exceeds parallel max in every
cell. Median and min agree in direction in every cell.

Two premises on every parallel arm, either of which would make a result vacuous:
Workers Launched == Workers Planned (a plan can say Gather and run with zero workers, and
it still says Gather), and chunk groups read, which was 27 of 27 in every cell — nothing
here is confounded by zone-map pruning. Host loadavg 0.70 to 1.29 throughout. This host is a
shared workstation, and contention biases against finding a parallel speedup, since the
4-worker arm needs four free cores and the serial arm needs one; the effect was found anyway.

3. The issue's stated cause is refuted by its own arithmetic

The title says the planner goes wrong "because Gather prices columnar rows at the heap rate".
There is no heap rate and columnar rate. cost_gather charges
parallel_tuple_cost * rows, and the row count is identical for both tables on the same
query, so the charge is identical:

	serial cost	Gather tuple charge at 0.1	as % of serial	flips to Gather at
columnar	83,196	99,999	120%	0.060
heap	158,109	99,999	63%	0.030

The whole difference is the denominator. The doc's supporting sentence is wrong the same way:
"a columnar scan ships fewer, already-decoded rows" — it ships 999,987, the same as heap.
What differs is tuple width, 3 projected columns against 14.

The doc is also wrong that "a heap scan on the same shape also flipped ... about half the
default rate picks the faster plan". At 0.05 columnar flips and heap does not; heap needs
0.030.

4. Two mechanisms, both real, and they compound

(a) cost_gather is width-blind, and over-prices narrow tuples by 1.92x. Hold bytes
shipped constant and vary the tuple count:

estimator check: a query shipping ~1 row divides at 0.90 of ideal (serial/4 = 44.3 vs 49.4 measured, 4 workers launched)
arm A:   999,987 rows x width 12  = 11.44 MiB   serial_min 176.2  par_min 67.7   gather_est 23.6 ms
arm B: 3,000,052 rows x width  4  = 11.44 MiB   serial_min 169.0  par_min 79.1   gather_est 36.9 ms

tuple-count ratio B/A = 3.00x   <- what cost_gather charges
measured gather ratio = 1.56x   <- what it costs

The gather share is estimated as parallel_total - serial_total / workers, which assumes the
scan divides perfectly. That assumption is checked rather than asserted (0.90 of ideal), and
both arms carry it identically, so it cannot decide the direction.

Narrowness is a projection property, not a storage-format one, so this half is core's and
applies to a heap with the same narrow projection. An honest fix here cannot be columnar-only.

(b) The serial columnar scan is under-priced, and inconsistently. Cost per millisecond of
real execution, serial, same query, same rows, with core's seqscan calibration as the
reference scale:

projection	columnar cost/ms	heap cost/ms	heap ÷ columnar
sel	347	858	2.47x
sel, a, b	385	846	2.20x
8 columns	516	765	1.48x
*	187	944	5.05x

The heap's figure is stable across widths, 765 to 944, a 1.24x spread, which is what makes it
usable as a reference. Columnar's runs 187 to 516, a 2.8x spread — the model is not merely
under-scaled, it disagrees with itself as the projection widens. The * row is the same
defect at its extreme: columnar takes 1279 ms against the heap's 167 ms, 7.6x slower, while
being priced at 1.5x.

Both mechanisms push the same way on a narrow projection: the serial side looks cheaper than
it is, and the parallel side looks dearer.

What I think this changes

• The because clause in the title is not supported and should be replaced.
• docs/limitations.md has two false statements to correct, separately from any fix.
• The half that is ours is (b), the scan cost model — and changing it is not a small
  matter. It is the scale every other path comparison is judged on, including the index-fetch
  penalty (Planner chooses an Index Scan on columnar for ordering; per-row fetch cost is not modelled and the plan is orders of magnitude slower #355, The #355 index-fetch penalty changes the estimate but not the plan: the cheaper path is already freed when it is applied #362) and the point-lookup regression Point lookup regressed 23.75 ms to 1251.88 ms once ANALYZE has run, and ANALYZE itself is pathologically slow on some shapes #171 exists for. Raising it to match
  reality could re-break what those fixed, so it wants its own issue and its own controls
  rather than being smuggled in under a parallelism ticket.
• The half that is core's is (a), and it is not columnar-specific.

Raw scripts and full output available; every number above is from a run whose fixture premises
are asserted in the same script that produced it.

[jdatcmd]

Follow-up: what a correct scan cost would and would not fix here

Measured, not predicted. A throwaway GUC added a base correction of the size #766 measures to
the columnar scan's run cost, and the plan sweep re-ran across all 30 cells. The knob was
reverted and is in no branch.

serial-chosen cells	13
flipped to parallel	4
parallel-chosen cells that regressed to serial	0

The four that flip are all three 999,987-row narrow projections and * at 2,000,197 — the
shape this issue was filed about. On sel, a, b at 999,987 rows the serial cost goes
83,196 → 165,096 and the plan becomes Gather at 140,925, a 17.2% margin.

The nine that do not flip are the finding. The timing run says the parallel plan is faster
in all 13 cells, so a correct cost model would flip all 13. It flips 4. The remainder are
the 2,000,197 and 3,000,052-row cells, where the Gather tuple charge is 200,020 and 300,005 —
far beyond what any base correction reaches. Those are held by the width-blind per-tuple
charge in core's cost_gather, which an access method cannot change.

So this issue should not simply be closed as "blocked on #766"

• The shape the issue describes is subsumed by The columnar scan is priced 1.9x to 3.4x below the heap per unit of work, and seq_page_cost decides whether that is a defect #766.
• Nine of the eleven measured cells are not, and stay wrong however honestly the scan is
  costed, because their cause is parallel_tuple_cost * rows being blind to tuple width.

That half is not columnar-specific — it applies to a heap with the same narrow projection —
and it is upstream work or nothing. The honest resolution is to record it as a documented
limitation with its mechanism stated (PR #767 does that) and let #766 carry the half that is
ours.

Instrument note, because the first run said the opposite

The first attempt reported 0 of 13 flipped and read as a clean refutation. The knob had
added the correction to the startup cost as well as the run cost, and a startup cost is paid
by every worker and never divided among them — so both sides rose identically and no cell
could flip whatever the correction was. A null result from an instrument that cannot produce a
positive one is not a null result.

[OffgridwithJD]

Provenance note: every wall-clock figure on this issue was measured on an --enable-cassert
build, and nothing here says so. Recording it now rather than when someone quotes it.

The bench runners now refuse an assert prefix (#773), which is what stops this recurring — but
the numbers already published here predate that guard and were taken through it.

What is and is not affected

Unaffected — the plan-choice result. Costs are deterministic, so "the planner chose the
serial scan in 11 of the shapes tested" stands exactly as written, as does the whole costing
analysis: parallel_tuple_cost charged per row and blind to width, the 3.00x charged against
1.56x actual, the 0.060 / 0.030 / 0.100 flip rates. None of that is a clock reading.

Affected — every duration and every ratio built from durations. The 1.8–2.6x medians and the
non-overlap with its 1.45x narrowest margin are all wall clock on an assert build.

How much, honestly

Unknown for these shapes, and I would not guess. The one place the skew has been measured
rather than reasoned about is #768's per-column ladder, where assert against non-assert came out
at 2.5% — well inside that issue's stated scatter. So the effect is probably small here too.

But "probably small" is not the same as measured, and the direction is not neutral: assert
overhead is allocation- and reset-shaped, and a columnar arm decoding varlenas allocates where a
heap arm does not, so a columnar-vs-heap ratio is exactly the shape where it need not cancel.
That is the reason to say so rather than to assume it away.

What I would do with this

Nothing urgent. The conclusion of this issue does not rest on the durations — it rests on the
costing arithmetic, which is unaffected. But if anyone re-derives or re-quotes the 1.8–2.6x band,
re-run it on a non-assert prefix first; the guard added in #773 will now refuse the wrong one
rather than let it through quietly.

(Same note applies to #752, posted there.)

[jdatcmd]

Re-measured on the non-assert build. The figure in docs/limitations.md was taken on
/usr/local/pg17, which is --enable-cassert, so every timing behind this issue needed
re-taking (see #773, which now makes the bench runners refuse an assert build).

The issue holds, and on this shape it is worse than the recorded 2.5x.

4,000,000 rows, 5.0% selective (200,000 rows), SELECT sum(a), sum(b), sum(c) ... WHERE k < 50
pg17_nc (non-assert), min of 7

  what the planner CHOOSES at default settings, nothing forced:
    Gather nodes in the default plan: 0        <- it chose serial
    default plan cost: 94499.68..94499.69

  each plan forced, only so it can be TIMED, each asserting the plan it ran:
    PREMISE serial arm 0 Gather nodes, parallel arm 1
    serial   153.100 ms
    parallel  44.054 ms
    ratio    3.48x faster in parallel
    answers identical: yes

Two notes on method, because both are ways this measurement goes wrong:

• the choice is read before anything is forced. parallel_setup_cost = 0 and
  min_parallel_table_scan_size = 0 make the planner pick Gather everywhere, so a run that
  sets them and then reports "the planner chose parallel" has measured its own GUCs. They are
  set only on the timing arm, after the choice has already been recorded at defaults.
• both arms assert the plan they ran, by counting Gather nodes, so neither timing can be
  of a plan other than the one it is labelled with.

This is a different fixture from the one in the doc (4 columns touched rather than 3, 5%
selectivity), so 3.48x is not a correction of 2.5x -- it is the same phenomenon measured again
on a build where the numbers mean something. The doc's figure should be re-taken on
pg17_nc before it is quoted anywhere else.

The care the issue asks for still stands and I have not started on it: any fix has to price
what a columnar scan actually ships rather than discount until it wins, and it needs a control
on a shape where serial is genuinely right. Noting also that #766 -- whether the columnar scan
cost model can be resolved on this box at all -- is parked by the owner, and a Gather-cost
change lands in the same place.