pgcolumnar.enable_metadata_count is an orphaned GUC, and count(*) loses to a parallel scan by default

[jdatcmd]

Found by running the full benchmark suite against current main and comparing to the recorded bench/sample_output_pg17.txt.

What the benchmark showed

count(*) on the full table, 6,000,000 rows, PostgreSQL 17 non-assert:

	median
recorded in bench/sample_output_pg17.txt (3M rows, format 2.1)	0.02 ms
current, default settings	6.52 ms
current, max_parallel_workers_per_gather = 0	~1.75 ms

Scale doubled, so some increase is expected, but not from 0.02 ms to 6.52 ms.

Two separate things

1. The GUC is orphaned. columnar_enable_metadata_count is declared in columnar.h:159, defined in columnar_vector.c:74, and registered as pgcolumnar.enable_metadata_count in columnar_tableam.c:1193 with a description promising "Answer count(*) from catalog metadata without scanning". Nothing reads it. grep -rn 'columnar_enable_metadata_count' src/ returns only the declaration, the definition, and the registration.

git log -S says why: the last commit touching it is 881fa51 Phase H2: remove the 1.0-dev (2.2) on-disk format, catalog, and selector. The consumer went with the 2.2 path and the knob stayed behind. So the setting is user-visible, defaults to on, documents a behaviour, and does nothing.

count(*) is still answered without decoding column data: the vectorized aggregate path sums each row group's rowCount (columnar_vector.c:1008). So the capability survives; what was lost is the dedicated catalog-level shortcut and, with it, the meaning of the GUC.

2. The planner prefers a parallel scan. With parallelism at its default, EXPLAIN shows Gather over Partial Aggregate rather than the columnar path. Disabling parallelism gives Custom Scan (ColumnarScan) with Columnar Vectorized Aggregates: 1 and runs about 3.7x faster on the benchmark table. The near-constant-time path is losing on cost to a plan that reads the table.

Suggested resolution

Either wire the GUC back to something real or remove it, and either way make the costing reflect that the columnar aggregate path does not scan. A knob that does nothing is worse than no knob, and docs/features.md:48 currently promises the behaviour the knob names.

Not urgent for correctness: results are right either way. It is a performance and honesty issue.

[jdatcmd]

Stronger evidence: the comparison is not confounded by scale after all.

docs/benchmarks.md carries a previously documented run at the same 6,000,000 rows on the same PostgreSQL 17 non-assert configuration, and it records count(*) at 0.03 ms. Today's run on 2f1320f measures 6.52 ms for the identical query at the identical scale. So this is a straight regression, not the 3M-to-6M difference I first attributed it to.

The same comparison shows the rest of the engine moved the other way over that period, which is worth stating so this reads as one regression rather than general drift:

	previously documented (6M)	today (6M)
columnar table-only, none	81 MB	40 MB
columnar table-only, zstd	48 MB	5.95 MB
sum/avg over int	142.34 ms	6.50 ms
projection, 3 of 8 cols	48.00 ms	74.78 ms
count(*)	0.03 ms	6.52 ms

Size improved 8x and the aggregate path improved 22x. count(*) is the one that went backwards, and the projection query is somewhat slower too, which may be the same planner-preference effect and is worth checking when this is picked up.

docs/benchmarks.md is the file that still says count(*) "is answered from catalog metadata and does not scan". The benchmark PR updates that text to describe what actually happens and points here.

(Reposting: the previous comment lost two table cells to shell quoting.)

[jdatcmd]

Fixed in three parts, each gated on PG18 and PG19.

#139, the orphaned setting. pgcolumnar.enable_metadata_count is removed
rather than wired back. The behaviour it named is not a separable path:
count(*) is one case of the vectorized aggregate answering from row-group
metadata, and the escape hatch a user would want already exists correctly scoped
as pgcolumnar.enable_vectorization = off. Docs now describe the real mechanism,
and differential.sh part 7 keeps its meaning through the setting that really
selects the path.

#140, the costing. The path was priced at the cheapest scan path's total
cost, which a parallel Gather over Partial Aggregate beats by dividing that
same cost across workers. It is now priced for what it reads, one metadata entry
per row group, falling back to the scan cost when the storage has a delete vector
because that is when the executor really scans.

#141, the latency. Fixing the plan was not enough, and measuring rather than
assuming is what caught it: the plan was right and count(*) at 6M rows still
took about 6 ms. Execution time tracked row-group count (5.2 ms over 40 groups,
1.4 ms over 10), because the metadata aggregate read every column's zone map for
every row group and then used none of it for a pure count(*).

Measured on the same table, PG17 non-assert, 6,000,000 rows, EXPLAIN ANALYZE,
five runs:

row groups	before	after
40 (default limits)	5.2 ms	0.033 ms
10	1.4 ms	0.029 ms

Constant with respect to row groups, and back to the 0.02 ms class this was
measured against originally. The plan at default settings is
Custom Scan (ColumnarScan) with Columnar Vectorized Aggregates: 1, no
Gather.

Each behaviour is pinned by a test proven to fail without the change: the plan
choice by mutating the costing back, and the zone-map skip by counting scans of
pgcolumnar.zone_map in both directions.