CREATE INDEX decodes every column, though index_build_range_scan is told which ones it needs

[jdatcmd]

Summary

pgcolumnar_index_build_range_scan opens its reader with no projection:

readState = PgColumnarBeginRead(table_rel, snapshot, NULL, NULL, 0, NULL);

so building an index on one column of a wide table decodes every column. It does
not have to: the callback receives struct IndexInfo *index_info, which carries
ii_IndexAttrNumbers and the predicate and expression trees. Everything needed to
build the projection is already in the argument list.

Measured

300,000 rows, 20 columns (one int key and 19 text of 80 bytes), index on the key
alone:

	columnar	heap
CREATE INDEX ON w (k)	517 ms	442 ms

Columnar is slower than heap at building a single-column index on a 20-column
table, which is the shape columnar storage should win by a wide margin. It reads
1/20th of the data and takes 17 percent longer.

For contrast, on the same table through the custom scan, which does get a projection:
SELECT max(k) is 10 ms with projection and 21 ms without.

Why it is worth its own issue

This is the table-AM interface having nowhere to put a projection, which we normally
work around with the custom scan node. index_build_range_scan is one of the paths
that cannot use that workaround, and unlike most of them it does not need to,
because the information is in its own parameters.

Suggested fix

Build a Bitmapset from index_info->ii_IndexAttrNumbers, plus pull_varattnos over
ii_Expressions and ii_Predicate for expression and partial indexes, and pass it to
PgColumnarBeginRead. The existing pgcolumnar_projected_columns in
columnar_customscan.c is the same computation over a different source and is worth
reusing rather than rewriting.

Care needed on two points:

• a partial index needs the predicate's columns as well as the key's, or the
  predicate is evaluated against unset slot values;
• an expression index needs every column its expressions reference.

Both are the same class of bug as the system-column and whole-row rejections already
handled in columnar_customscan.c, so the test should cover a plain index, an
expression index and a partial index, and compare the built index's contents against
the heap equivalent rather than only its row count.

Not in scope here

ANALYZE shows a larger gap on the same table (622 ms against heap's 92 ms) and is
not fixable the same way: the analyze callbacks are not told which columns ANALYZE
was asked for, so the AM cannot project. That is a genuine interface limit rather than
an oversight, and it needs its own issue if we want to pursue it.

[ChronicallyJD]

Taking this, unless you were about to.

It is the same family as what I have just been measuring on #401, and worth saying so
because the two together make a pattern rather than two incidents.

#401, corrected: on a join, our vectorized aggregate cannot apply, because it only sits
directly above our scan. Same data and query without a join, we win 1.9x. With one, we lose
1.27x. The join does not cost us slot overhead; it disables the thing we are fast at.

This issue: index_build_range_scan cannot use the custom scan, so it gets no
projection, and building a one-column index on a twenty-column table reads all twenty.

Both are the same shape: a path where the table-AM interface gives us nowhere to put a
projection or a vectorized operator, so we fall back to reading everything row-at-a-time and
lose to heap on a workload we should win.

The difference, and it is why yours is the better issue, is that this one does not need a
new interface. index_info already carries ii_IndexAttrNumbers, ii_Expressions and
ii_Predicate. The information is in the argument list and we throw it away. #401 needs an
answer to a much larger question.

Plan is yours as written: build the bitmapset from the key columns plus pull_varattnos over
the expression and predicate trees, reuse pgcolumnar_projected_columns rather than
rewriting the same computation, and cover plain, expression and partial indexes in the test.

I would add one assertion to the test beyond correctness: that the projection actually
narrowed, by comparing the column count the reader opened rather than only the wall clock.
A projection fix that silently did nothing would still pass a timing check on a quiet
machine, which is the failure mode we have both hit this week.

Working on the bench, PR when the five-major matrix is green.

[jdatcmd]

PR #420 supersedes #416 and #419, which we closed in favour of each other's within minutes of each other. My fault at the root: I filed this issue, designed it here, then coded it without claiming it.

The disagreement between those two PRs was over whether the parallel branch of index_build_range_scan mattered. It does, and @ChronicallyJD had it right: with workers available it is the only branch that runs (9 log entries across 5 pids, 0 serial), and with every parallel GUC at its default a 459 MB columnar table takes it. A serial-only fix measured 568 ms against heap's 563 ms on that arm. #420 projects both readers and measures 73 ms.