Opportunities from Abadi's materialization strategies and MonetDB/X100, with what we already implement

[ChronicallyJD]

Two more papers, both execution-layer where #403 was storage-layer.

• Abadi, Myers, DeWitt, Madden. Materialization Strategies in a Column-Oriented DBMS.
  ICDE 2007.
• Boncz, Zukowski, Nes. MonetDB/X100: Hyper-Pipelining Query Execution. CIDR 2005.

Same rules as #403: worked from the papers, anything we build is ours. Ranked, with what
we already have beside it.

First, the thing we already got right

X100's central argument is that neither extreme works. Tuple-at-a-time Volcano iteration
spends its time in interpretation, and MonetDB/MIL's full column materialization becomes
memory-bandwidth bound. Their answer is vectors sized to stay in CPU cache.

Their measured motivation, TPC-H Q1:

system	time
MySQL 4.1	26.6 s
MonetDB/MIL	3.7 s
MonetDB/X100	0.50 s
hand-coded C	0.22 s

MySQL achieved an IPC of 0.7 and spent under 10 percent of its time on the actual
arithmetic.

We already do this. src/columnar.h:47:

#define COLUMNAR_NATIVE_VECTOR_LENGTH 1024	/* values per vector (fixed) */

Storage chunk group defaults to 10,000 rows, and the execution and skip vector is 1024
values. That is the separation X100 argues for, and 1024 is the size range they land on.
Recording it because it is worth knowing we are aligned, and because the next person to
read this paper should not file it as a gap.

1. Position-list intersection before materialization

The item worth measuring. Abadi's late materialization works like this:

first scan R.a and output the positions in R.a that satisfy the predicate. Repeat with
R.b and R.c. Next, use position-wise AND operations to intersect the position lists.
Finally, re-access R.a, R.b, and R.c and extract the values of the records that
satisfy all predicates.

Position lists are cheap to intersect, 32 or 64 at a time when held as bit-strings.

We have the ingredients: vector-level skipping (nativeSkipVec, the
Columnar Vectors Skipped counter), column projection, and deferred slot decode. What I
cannot tell from reading is whether multiple predicates on different columns intersect
their surviving positions before any values are materialized, or whether we materialize the
projected columns for surviving vectors and let a residual qual filter rows afterwards.

The q2 plan from today's work is suggestive but not conclusive:

Columnar Chunk Groups Read: 118 of 667
Columnar Vectors Skipped: 40
Rows Removed by Filter: 17,295,680

17 million rows removed by a filter means 17 million rows reached a filter. Whether they
were materialized first is the question. That is a measurement, not a claim, and it is
the first thing I would establish.

Abadi is also explicit about when late materialization loses:

the column reaccess cost at tuple reconstruction time is high

and worse when positions are not sorted, which is what a join does to them. So this is a
trade with a real downside, not a free win. The paper gives an analytical cost model for
choosing, which is more useful to us than the strategy itself.

2. Branch predication in selection

X100 Figure 2 measures the difference directly:

/* branch version */
if (src[i] < V) out[j++] = i;

/* predicated version */
bool b = (src[i] < V);
out[j] = i;
j += b;

The branch version has a worst case around 50 percent selectivity, where the predictor
cannot win. The predicated version is flat across selectivity and slightly more expensive
on average.

Our filter evaluation runs over 1024-value vectors, which is exactly where this applies.
Whether it is worth doing is a microbenchmark, and the paper says why the answer depends on
selectivity rather than being uniformly yes.

3. Vector size against column count

An open question rather than a finding. 1024 values of an 8 byte type is 8 KB per column.
A vectorized aggregate touching ten columns is working over 80 KB of live vector, which is
past L1 on most parts and into L2.

X100's argument is about staying in cache, so the right vector length may depend on how many
columns an operator touches at once. Ours is a fixed format constant, so this is not a knob
to turn casually. Worth knowing before anyone proposes widening a vectorized operator, and
it connects to the lesson in my own #289 work that eager per-group work regressed narrow
scans.

What I would break out

Only item 1, and only as a measurement first: establish whether multiple predicates on
different columns intersect positions before materializing. If they already do, this issue
closes with a note. If they do not, Abadi's cost model is the right basis for deciding
whether to, because the paper is equally clear about when the strategy loses.

Items 2 and 3 I would leave recorded here. Both are microbenchmark questions, and neither
should be touched without one.

[ChronicallyJD]

Measured. We do not intersect positions, and the cost that buys is worth having.

Two experiments on the bench, 2,000,000 rows, serial, bloom off.

1. Does the conjunction's selectivity reduce what we materialise? No.

A wide pad column, and a deliberately scattered b so that no 1024-value vector can
be ruled out by its zone map. Any saving therefore has to come from position-level
intersection rather than vector skipping. T_pad - T_nopad isolates the cost of
materialising pad.

b predicate	survivors	T_nopad	T_pad	pad decode
b % 2 = 0	1,000,000	165.6	1,821.3	1,655.8
b % 10 = 0	200,000	150.8	1,803.2	1,652.3
b % 100 = 0	20,000	137.0	1,807.5	1,670.5
b % 1000 = 0	2,000	136.8	1,808.7	1,671.9
b % 10000 = 0	200	138.1	1,801.9	1,663.8

Survivors fall 5,000x. Decode cost moves 1.2 percent. Confirmed by the counters:

Columnar Chunk Groups Read: 14 of 14
Columnar Vectors Skipped: 0
Rows Removed by Filter: 1,999,800

Two million rows materialised to return two hundred.

The code says why, and it is a design statement rather than an oversight
(src/columnar_reader.c:134):

When any predicate's per-vector zone map rules a vector out, its rows are neither
decoded nor emitted.

Our granularity is the 1024-row vector, not the position. Abadi intersects positions;
we prune vectors. The fixture scattered b precisely so that mechanism had nothing to
work with, which is the case this measures.

2. Is that cost decompression or per-value work? Per-value, mostly.

This decides whether position-level work could avoid it. Decompression is per block and
unavoidable without skipping a whole vector. Per-value work is per position, so it is
avoidable in principle.

Same row count, same 160 byte width, one column compressing about 43x better:

table	on disk	T_nopad	T_pad	pad decode
mz_comp (repeat('x',160))	992 kB	138.7	587.9	449.3
mz_rand (repeat(md5(g),5))	42 MB	132.0	746.6	614.6

43x the bytes, 1.37x the time. If decompression dominated, a 43-fold difference in
compressed size would not come out as a third more time.

Splitting it: roughly 449 ms is per-value work that is present even when the column is
almost free to decompress, and roughly 165 ms is attributable to actually moving and
decompressing 42 MB. So about three quarters of the cost is per-position, at about
0.22 microseconds per value.

What that means

The cost we pay for materialising rows the filter then discards is mostly the kind
position-level late materialisation would avoid. Had this come out the other way, with
decompression dominating, position lists would have bought nothing and this issue could
have closed.

It did not come out that way, so item 1 has a measured case behind it.

I would still not implement it off this alone. Abadi is explicit that late materialisation
loses when column re-access is expensive, and worse when positions arrive unsorted, which
is what a join does to them. The next step is his cost model rather than the strategy: what
it would take to decide, per scan, whether to materialise a projected non-predicate column
eagerly or at surviving positions only.

Scope, honestly

• One wide text column. Per-value cost for a varlena includes length decoding and
  pointer construction, so a fixed-width column will not split the same way. Worth
  repeating on float8 before anyone sizes the work.
• The scattered predicate is deliberately the worst case for vector skipping. On clustered
  data our existing mechanism does the job, which is what the clustering measurement on
  benchmarks.md: the zone-map explanation is half wrong, and the correlation argument behind it does not hold #391 showed.

One thing I got wrong on the way

My first attempt at experiment 2 used gen_random_bytes, which needs pgcrypto. The setup
failed, I had suppressed the error, and the script timed and reported 0.176 ms scans of
tables that did not exist. For two million rows that is an absurd number and I should have
caught it from the value alone.

The rerun asserts row count and column width before any timing runs, which is what produced
the table above. Same class as #321, where a green suite was measuring a fallback rather
than the path it claimed.

[ChronicallyJD]

Repeated on float8. The architectural finding holds; the value of fixing it does not.

jd asked for this before sizing the work, and it was the right call. The text numbers
overstate the opportunity by more than an order of magnitude on fixed-width columns.

The flatness holds, so the finding about granularity stands

fz_rand, 2,000,000 rows, pad float8 = random(), scattered b:

b predicate	survivors	pad decode
b % 2 = 0	1,000,000	181.6 ms
b % 100 = 0	20,000	178.5 ms
b % 10000 = 0	200	175.1 ms

Survivors fall 5,000x, decode moves 3.7 percent. Same conclusion as text: no position
intersection, materialisation is per surviving vector.

The per-value share collapses

Same split as before, compressible against incompressible:

type	on-disk ratio	decode, compressible	decode, incompressible	time ratio
text (160 B)	43x	449.3 ms	614.6 ms	1.37x
float8	16.8x	29.3 ms	178.2 ms	6.1x

For text, 43x the bytes cost 1.37x the time, so per-value work dominated. For float8, 16.8x
the bytes cost 6.1x the time, so data volume dominates and the per-value floor is small.

Per value:

text    449 ms / 2,000,000 = 0.22   us per value
float8   29 ms / 2,000,000 = 0.0125 us per value

An 18x difference. The text figure was varlena handling, the length decoding and pointer
construction I flagged as a caveat, and not something a float8 pays.

What this does to sizing

Position-level late materialisation can only recover the per-value component. The
volume component is decompression, which is per block and has to happen whether one row in
the block survives or all of them do.

So the recoverable cost is roughly 449 ms per 2M rows for a wide text column and roughly
29 ms per 2M rows for a float8. On a numeric fact table, which is what the TSBS
benchmark is and what most of ours look like, this is close to nothing.

Had I sized this off the text result alone I would have been wrong by about 18x.

Revised recommendation

Do not build position-level late materialisation as a general scan feature. The measured
benefit does not carry to the column types that dominate our workloads.

The narrower version is still defensible: materialise wide varlena projected columns at
surviving positions, and leave fixed-width columns as they are. That is close to what
columnar_slot_decode_upto already does by attribute prefix, and it is a smaller change
than a position-list rewrite of the scan.

I would want one more measurement before even that: how common is the shape, a wide text
column projected past a selective filter on other columns, in anything we actually care
about. If the answer is "rare", this closes as measured and declined, which is a fine
outcome for an issue.

One thing this run did not test, despite the labels

I ran the sweep with pgcolumnar.enable_vectorization off and on, expecting to compare code
paths. The plan control shows both arms took the same one:

Aggregate (actual rows=1.00 loops=1)
  ->  Custom Scan (ColumnarScan) on fz_rand (actual rows=200.00 loops=1)

A plain Aggregate, not a vectorized node, so the vectorized aggregate never engaged and
the two arms are the same measurement twice. That is why they agree to within noise. The
"vectorization ON" numbers are not evidence about the vectorized path, and I am not going
to present them as if they were.

[ChronicallyJD]

Proposing this closes as measured and declined

Both experiments are on the issue. The finding stands, we prune vectors rather than
intersect positions, but the float8 rerun showed the recoverable cost is about 29 ms per
2M rows on a fixed-width column against 449 ms on wide text. On a numeric fact table,
which is what our workloads look like, that is close to nothing.

I would rather close this than leave an issue open that says "we measured it and decided
not to". The measurement is the value and it is recorded.

Happy to leave it open if you would rather keep the varlena-only variant visible.

[ChronicallyJD]

Withdrawing my recommendation to close this. New evidence, and it is not close.

I proposed above that this closes as measured and declined. That was built on a fixture
that could not show the effect, and ClickBench (#421) supplies one that does.

What I measured then

Fixed-width columns, no wide text, a filter that was not very selective, and no
SELECT *. Recovered cost: 29 ms per 2M rows. On that evidence, declining was right.

What ClickBench measures now

SELECT * FROM hits WHERE URL LIKE '%google%' ORDER BY EventTime LIMIT 10, 11,110,833
rows, 105 columns, on the real dataset. Same table, varying one thing:

variation	heap	columnar
as written, SELECT *	727 ms	8,099 ms
identical, but SELECT EventTime	711 ms	1,668 ms

6,431 ms, 79 percent of the query, is materialising columns. 1,728 rows of 11,110,833
survive the filter, which is 0.016 percent. We decode 105 columns worth of candidate rows
to return ten.

The control matters as much: the same query shape with an integer predicate
(count(*) WHERE CounterID = 62) runs in 21 ms against heap's 587 ms. The scan is not
slow. The materialisation is.

Why my fixture could not see this

Four things have to line up, and I had none of them:

• wide rows, so materialising is expensive. 105 columns, not 8.
• a very selective filter, so most materialised rows are discarded. 0.016 percent, not
  a few percent.
• SELECT *, so there is no projection already saving the work.
• text columns, so each materialised value carries a varlena header and real bytes.

My fixture had fixed-width columns and a mild filter, which is the shape where positions
buy least. I built the case against the feature out of the data I chose. That is the same
error I made on this issue's sibling with random() floats, and I did not recognise it the
second time.

What I am not claiming

I am not claiming 6,431 ms is all recoverable. Some of those columns are needed for the ten
rows that survive, and a position list has its own cost, which is exactly what this issue
was opened to measure. What changed is the size of the prize: from 29 ms per 2M rows to
most of the runtime of the worst query in a published benchmark.

That is worth measuring properly rather than declining. Re-opening with the ClickBench
fixture, and I will post the decomposition here rather than in a comment on the benchmark.

[ChronicallyJD]

Measured. Item 1 answered, the ceiling quantified, and it does not close this issue alone.

Taking this properly, as I said I would after withdrawing my "close as declined".

1. The mechanism question, answered from the code

whether multiple predicates on different columns intersect their surviving positions
before any values are materialized, or whether we materialize the projected columns for
surviving vectors and let a residual qual filter rows afterwards

Both, at different granularities. pgcolumnar_native_build_skipvec
(columnar_reader.c:846) walks every predicate against per-vector zone maps and sets
skip[v] if any predicate excludes that 1024-row vector:

for (v = 0; v < vecCount; v++)
    for (p = 0; p < rs->numPredicates; p++)
        if (native_zone_excludes(pred, att, z, rs->skipContext))
        { skip[v] = true; any = true; break; }

That is a conjunction across predicates, so we do intersect. At vector granularity,
from min/max, never at row positions. Within a surviving vector every projected column is
materialised for all 1024 rows and the executor's qual filters afterwards.

So Abadi's strategy is not implemented, and the gap is exactly the one the paper describes.

2. My attempt to measure the ceiling by hand failed, and the reason is our own code

I tried to perform late materialisation manually: select positions with a narrow scan, then
fetch the wide columns for the survivors.

as written: SELECT * ... LIKE ... ORDER BY EventTime LIMIT 10        7933 ms
narrow: SELECT EventTime only, same filter and top-N                 1670 ms
"late materialisation" by hand, via ctid                            11213 ms   <- WORSE

That is a plan, not a strategy. EXPLAIN says why:

Tid Scan on hits_col
  InitPlan 1
    ->  Parallel Custom Scan (ColumnarScan) on hits_col
          Filter: (url ~~ '%google%'::text)
          Columnar Projected Columns: 105        <- selecting ctid projected EVERYTHING

Selecting ctid is a system column, and PgColumnarProjectionFromAttnos treats a
system column as "read every column". So the subquery that was supposed to be the cheap
narrow scan read all 105 columns, and the outer TID scan then read them again. The oracle
was defeated by our own projection escape.

Recording it because it is a genuine constraint on any hand-rolled experiment here, and
because it would have been easy to report 11,213 ms as evidence against the technique.

3. The ceiling, derived instead from the marginal cost of materialising a row

Measured on the same table: a pushdownable predicate, narrow versus wide, so the difference
is materialisation and nothing else.

	rows	narrow	wide	difference
CounterID = 62	82,019	29.67 ms	85.34 ms	55.67 ms

0.00068 ms per row to materialise all 105 columns.

q24's filter passes 1,728 rows of 11,110,833. So materialising every column for exactly
the survivors costs about 1.2 ms.

	q24
today, materialising 105 columns for every row that reaches the filter	7,933 ms
the selection alone, one column	1,670 ms
plus materialising 105 columns for the 1,728 survivors	+ ~1.2 ms
late materialisation ceiling	~1,671 ms
recoverable	6,262 ms, 79 percent

That is derived independently of the SELECT * versus SELECT EventTime decomposition I
posted earlier, and it lands on the same number, which is the reason to believe it.

4. The part that changes the recommendation: it is not enough

Heap runs q24 in 665 ms.

So even with a perfect implementation of this issue, q24 goes from 11.9x slower than heap
to 2.5x slower. The remaining 1,670 ms is the LIKE scan itself, and that is #426, not
this issue.

Neither issue alone makes this query win. #405 removes 79 percent of the cost and leaves
us losing. That is worth knowing before either is scheduled, and it is not what I would
have guessed from the 79 percent figure on its own.

5. And it does not win everywhere, which the paper predicts

The same measurement on a shape where nearly every scanned row survives:

	narrow	wide	what late materialisation saves
CounterID = 62, 82,019 of 82,019 survivors returned	29.67 ms	85.34 ms	approximately nothing

Late materialisation pays when selectivity is high and the projection is wide. Abadi
says exactly this, and now we have our own numbers for it rather than the paper's.

Recommendation

Do not close this. The measurement I built the "declined" recommendation on could not
have shown the effect: fixed-width columns, a mild filter, no SELECT *, no text. Four
things had to line up and I had none of them.

But do not schedule it as a win on its own either. The honest framing is:

• Opportunities from Abadi's materialization strategies and MonetDB/X100, with what we already implement #405 is worth about 79 percent of the worst ClickBench query, and a comparable share
  of q22 and q23, which have the same shape.
• It needs Text predicates cannot be pushed down, so a LIKE scan decodes every value: 2.2x slower where an integer predicate is 27.7x faster #426 to turn any of those into a win, because the selection is the floor.
• A cost model is needed with it, since the technique loses on unselective or narrow
  shapes, and we now have both sides measured.

I am not taking the implementation on this pass. What I would want first is the plumbing
question answered: whether a position list can be carried from the vector filter through to
slot materialisation without changing the table-AM scan interface, which is the same
interface constraint behind #413 and #363.

[jdatcmd]

Reviewed item 1 with a multi-agent investigation of the execution path, a
synthesized TDD plan, and an adversarial critique that overturned its own
recommendation. Full plan in design/ISSUE_405_LATE_MATERIALIZATION.md. The
two crux findings were re-verified against main by hand, not taken on report.

The correction to the framing

Your measurements are right, and they point at a real gap, but the gap is in
cheap work, and the workload that motivates it cannot reach the code that has
the gap.

• The row path already does position-level late materialization.
  pgcolumnar_native_next_row (columnar_reader.c:2206-2268, No late materialization: decode cost scales with rows scanned, not rows emitted #452 Phase 1a)
  decodes qual columns, runs the filter, and reads payload columns only for
  survivors. So "a scattered predicate materializes every projected column for
  every row that reaches the filter" is false on the row path. This is where the
  expensive per-value work lives (varlena decode via PgColumnarDecodeValue), and
  it is already solved.
• The only path that lacks it is the batch-fold aggregate path, and that path
  is byval-only: pgcolumnar_batch_shape_eligible (columnar_vector.c:3048)
  rejects any non-attbyval projected column, with a comment naming
  URL LIKE '%google%' and stating varlena falls back to the row path. So q24's
  text payload never reaches the fold path, and the per-discarded-row residual on
  the fold path is a single fetch_att load out of an already-decoded buffer, not
  a decode.

So this does not advance q24, and the reason is structural (varlena -> row
path), independent of #426. And the fold-path win, if any, is bounded by a
wall-clock measurement not yet taken.

Plan: measurement-gated, honest prior is "not worth it"

The TDD plan is gated on a timing arm taken FIRST (Step 1). It isolates the
fold-path discarded-row residual as a fraction of fold runtime after decode. If it
does not clear a worth-optimizing threshold, the implementation slices are
dropped, not merged. Steps 2-4 (fold reorder, label split, cost-model guard on the
agg node — the scan node's custom_private is the wrong channel and would
misroute) run only if the number clears.

The decode-level variant that WOULD save your ~3/4 per-value cost is explicitly
out of scope: decode_delta/dod/for/gorilla/dict/fsst are sequential streams with
no cheap random-position access, so "decode the whole vector then keep survivors"
saves the copy but not the decode.

Recommendation

Keep this open, item 1 re-scoped to the fold path with the wall-clock gate. Items
2 and 3 stay recorded as microbenchmark questions. My honest prior is that Step 1
declines the fold slice, but the measurement decides it rather than an argument.

[jdatcmd]

Step 1 (the measurement gate): run, and it CLEARS — against my own prior.

Measured on PG18 non-assert, 4M rows, 8 byval int8 payload columns, filter
selectivity 1%, median of 7, serial pinned. The fold path (Columnar Vectorized Aggregates) was asserted in EXPLAIN before any timing was trusted.

The plan predicted the fold-path residual was "a single L1-resident fetch_att
load", low single digit percent, likely a no-op. Wrong. Isolating decode from
load with a constant vs random payload (same selectivity, same shape):

quantity	ms
payload LOAD cost (constant payload, 14 MB, near-free decode)	374
payload DECODE cost (random − constant, 255 MB)	122
load : decode	3.1 : 1
recoverable residual (slice removes fetch_att+stores for the 99% failing rows, keeps cursor advance)	222–315 ms = 41–58% of the wide query

The fetch_att on this path is ~11.7 ns per (row,col), ~35 cycles — not a
register load. It dominates decode 3:1, and it is paid for every non-skipped row
before the key check. So the batch-fold gap is a gap in the DOMINANT cost, not a
cheap one.

What the same measurement confirms about scope

• byval only. The fold path rejects varlena (batch_shape_eligible,
  columnar_vector.c:3048), so this does not help q24 — its text payload runs
  on the row path, where No late materialization: decode cost scales with rows scanned, not rows emitted #452 Phase 1a already defers. The win is for
  byval-wide-aggregate shapes (numeric-aggregate queries with many int columns and
  a selective filter).
• selectivity-gated. At 99% selectivity the recoverable residual falls to ~1%
  (measured), so deferral is a loss there. The cost model (Step 4) is required,
  not optional.

One near-miss worth recording: the first fixture (mixed sum(int4), parallel not
pinned) silently took the ROW path, not the fold node. A row-path measurement
would have shown late-mat already present and produced the opposite conclusion. It
was caught by asserting the plan node as a hard premise.

Decision

Gate CLEARS. Step 2 (fold-path deferral) is unblocked, scoped to byval aggregate
shapes with the cost-model guard. It is a real win for the numeric-aggregate
class and explicitly not for q24. Full numbers and plan in
design/ISSUE_405_LATE_MATERIALIZATION.md.

[jdatcmd]

Retraction: the Step 1 gate was invalid. There is no recoverable gap.

I reported the gate CLEARED at 41-58% recoverable. That was wrong, and I caught
it by building Step 2, verifying the work-done counter, and finding it read 0.

Two errors, both found by implementing

1. I modified the wrong path. The only place lacking position-level late-mat
   is pgcolumnar_native_batch_fold, and it is taken only for aggregates with
   no payload column (count(*)). Every sum(payload) shape reports
   Columnar Batch Fold: no and takes the row path instead. So the fold path
   never carries payload to defer, and my counter read 0 because the code never
   ran for a payload query.

2. The gate compared two different paths. It measured
   T_qualonly = count(*) (which batch-folds, a fast path) against
   T_wide = count(*) + sum(payload) (which takes the row path). The 374 ms
   "payload load cost" was the batch-fold-vs-row-path difference, not payload
   materialization. Apples to oranges.

The corrected, like-with-like measurement

Same row-path query, only selectivity varies (PG18 non-assert, 4M rows, 8 byval
int8 payload):

selectivity	T (ms)
1%	544
10%	735
50%	1519
99%	2448

T scales 4.5x with selectivity: payload cost already tracks how many rows pass,
which is what late materialization does. #452 Phase 1a already defers payload
on the row path. The 1% floor is qual + whole-vector payload decode (comp vs
rand at 1%: 421 vs 537 ms, so 116 ms is decode), which is not cheaply
position-deferrable.

Conclusion

The adversarial critique in the plan was right; I overturned it on a bad number,
and the corrected measurement restores it. Item 1 is already implemented by
#452 Phase 1a. Steps 2-4 are dropped, the Step 2 branch abandoned unpushed,
nothing merged. The only remaining possibility -- extending batch fold to payload
aggregates for column-at-a-time efficiency -- is a different optimization, not
late materialization, and out of scope here.

Recommend closing item 1 as done-by-#452. Items 2 and 3 remain recorded as
microbenchmark questions.

design/ISSUE_405_LATE_MATERIALIZATION.md carries the full retraction and the
verified architecture facts.

[ChronicallyJD]

Item 1 confirmed done-by-#452, from a second and independent direction

@jdatcmd — your retraction holds, and I can confirm item 1 from the source rather than only from the timing, which is worth having beside a measurement that once went the other way.

The row-path producer pgcolumnar_native_next_row (columnar_reader.c:2142-2151) is position-list intersection in all but name:

The columns the qual reads are decoded first, filter is asked whether the row can survive, and the remaining projected columns are decoded only if it can — otherwise their cursors are advanced past the row without allocating or copying anything.

So the payload of a failing row is never decoded, never materialised: exactly Abadi's "re-access the columns only for the records that satisfy all predicates." It is per-row rather than a batched position-AND, but the work avoided is the same, and for the byval payload this issue is scoped to, the skip is a free cursor += width. That is two independent lines of evidence now — your like-with-like timing (T scaling 4.5x with selectivity) and the code that decodes payload only for survivors.

Your retraction discipline is the reason this landed right: the Step 1 gate reported 41-58% recoverable, and it was caught not by more reading but by building Step 2 and finding the work-done counter read 0 — the false positive came from timing count(*) batch-fold against count(*)+sum row-path, two different paths. A retraction of your own positive result, caught by implementing it. That is the standard.

Item 1: agreed, closes as done-by-#452 Phase 1a. The only residual — extending batch fold to payload aggregates for column-at-a-time efficiency — is a different optimization (fold-path throughput, not late materialization) and out of scope here.

Items 2 and 3 stay as recorded microbenchmark questions, both real but low-payoff:

• Item 2 (branch predication in selection). X100 Fig 2 says the answer is selectivity-shaped — the branch loses near 50% selectivity, predication is flat and slightly dearer on average. Whether our 1024-value filter loop benefits is a microbenchmark I can run if we want it; the expected win is a fraction of a filter pass, not a query.
• Item 3 (vector length vs column count). A fixed format constant, not a knob to turn casually; recorded, not actionable.

So this issue is down to two low-priority microbenchmark questions with item 1 resolved. Happy to run the item-2 microbenchmark to close it out, or leave both recorded.