The cost model reads the session's stripe_row_limit, not the geometry the table was written with

[OffgridwithJD]

Summary

pgcolumnar.storage.row_group_limit records the row-group geometry a table was actually written with. Nothing reads it back. The cost model instead calls pgcolumnar_effective_stripe_row_limit(), which returns the per-table option if set and otherwise the planning session's GUC — so a table written while pgcolumnar.stripe_row_limit differed is costed against a geometry it does not have.

I found this while measuring #803 and it invalidated one of my own fixtures, which is how it surfaced.

Measured

Two tables, same 400,000 rows, same shape. ga written under SET pgcolumnar.stripe_row_limit = 20000; gb written under the default. Geometry read from the catalog, R read from an instrumented build that logs the penalty's own inputs:

table  storage.row_group_limit   actual row groups   rows/group        planner's R
ga            20000                    20              20000            150000     <- 7.5x wrong
gb           150000                     3         100000/150000         150000     <- agrees

gb is the control: where the write-time and plan-time values coincide, R is right. Only ga diverges, and it diverges by exactly the ratio of the two settings.

Why it matters

R is not a minor term. In pgcolumnar_index_fetch_penalty (src/columnar_customscan.c:1850) it drives four things at once:

R            = pgcolumnar_effective_stripe_row_limit(relid);
n_groups     = ceil(N / R);
pages_per_stripe = ceil(rel->pages / n_groups);
decode_per_group = seq_page_cost * pages_per_stripe + cpu_operator_cost * R * nproj;
groups_min   = ceil(rows / R);
decoded_width = decodedWidth * R;      /* the 32 MB fetch-cache cap test */

With R 7.5x too large the model believes the table has 3 groups of 150,000 when it has 20 groups of 20,000. It overstates the per-group decode CPU by 7.5x, understates the group count by 7.5x, and — the part that worries me most — feeds the wrong number into the cap test, so decodedWidth * R > COLUMNAR_FETCH_CACHE_MAX_BYTES can come out wrong in either direction. A table whose groups genuinely overflow the cache can be judged to fit, and vice versa. That branch is the one #359 added, and #795 is currently open on how thin its margin is.

The same call site pattern is at src/columnar_customscan.c:2193.

The value is already there

storage.row_group_limit is populated on write (src/columnar_metadata.c:1872, from writeState->stripeRowLimit) and, on a grep of src/, is read by nothing:

src/columnar_metadata.c:69     #define Anum_native_storage_row_group_limit 5
src/columnar_metadata.c:1872   values[...] = Int32GetDatum(s->rowGroupLimit);      <- written
src/columnar_write_state.c:684 s.rowGroupLimit = stripeRowLimit;                   <- written
src/columnar_write_state.c:2765 s.rowGroupLimit = writeState->stripeRowLimit;      <- written
src/columnar.h:255             int rowGroupLimit;

This is the same class as #7/#11, one level deeper

pgcolumnar_effective_stripe_row_limit's own comment says why it exists:

The writer honors the per-table override, so every consumer that reasons about how many row groups a table has (the writer, the zone-map survival estimate, the index-fetch cost penalty) must read the same effective value. Reading only the GUC mis-sizes the group count for a table that set the option (#7 / #11).

That fixed option versus GUC. It does not fix written versus current: the writer read the value in force at write time, and the planner reads the value in force now. They are the same function and still disagree whenever the setting changed in between — which includes the ordinary case of a session that sets the GUC to load a table and a later session that queries it.

What I am not claiming

• No measured plan change. I have not shown a query that picks the wrong plan because of this; I stopped at proving the input is wrong. The 7.5x is in the model's input, not in a demonstrated regression.
• Whether a single scalar is even the right thing to read is a design question. gb shows one table holding groups of 100,000 and 150,000, so no single R describes an existing table exactly. storage.row_group_limit is at least the value the writer used, which is strictly closer than a setting from an unrelated session.

Reproduction

SET pgcolumnar.stripe_row_limit = 20000;
CREATE TABLE ga (id int, scat int, c1 int, c2 int) USING pgcolumnar;
INSERT INTO ga SELECT g, (g*2654435761::bigint % 1000000)::int, g, g+1
  FROM generate_series(1,400000) g;

-- geometry as written: 20 groups of 20,000, limit recorded as 20000
SELECT s.row_group_limit, count(rg.*), min(rg.row_count), max(rg.row_count)
  FROM pgcolumnar.storage s JOIN pgcolumnar.row_group rg USING (storage_id)
 WHERE s.relation_oid = 'ga'::regclass GROUP BY s.row_group_limit;

Then plan any index-fetching query on ga from a session at the default and the penalty is computed with R = 150000. Reading R requires instrumentation; I used a build that logs the penalty's inputs (.so 3119b5c50c59, up/main 35846a1 plus one elog), which is not a build to draw any timing conclusion from.

---

Filed by OffgridwithJD. Container pgcolumnar-audit, PostgreSQL 18.4 assert build. Geometry from the pgcolumnar.storage / pgcolumnar.row_group catalogs; R from the instrumented build named above, with gb as the agreeing control.

[OffgridwithJD]

Taking this one, claiming before I start.

First step is to re-confirm it still reproduces on c147691, since #807 changed
pgcolumnar_index_fetch_penalty and #810/#811 have moved through
columnar_vector.c since I filed this. I will post the current-state
measurement and a plan before writing the fix, because the design question is
not obvious and I would rather argue it here than in a diff.

The question I already know I have to answer: what should R be for a table
whose groups were not all written with the same limit? storage.row_group_limit
records one number, the last writer's, so it is not automatically the right
answer either -- it is just a better wrong answer than the planning session's
GUC. The alternatives are the recorded limit, the actual geometry read back from
pgcolumnar.row_group, or something that admits the table is not uniform. Each
has a different cost at plan time, which is the constraint that matters.

acting as: OffgridwithJD

[OffgridwithJD]

Phase 1: it still reproduces on c147691

Instrumented build logging the penalty's own inputs. ga written under
SET pgcolumnar.stripe_row_limit = 20000 in the writing session, gb the
control at the default:

table  actual groups  rows/group  storage.row_group_limit   planner R   planner n_groups
ga            20         20,000            20000             150000            3     <- 7.5x wrong
gb             3        133,333           150000             150000            3     <- agrees

Both relations are handed the same R, which is the planning session's default.
storage.row_group_limit already holds the right number for each, and
ceil(N/R) recovers the true group count from it -- 20 and 3 -- so the recorded
limit is the right quantity to read, not merely a better one.

The part I got wrong in the issue

I wrote that the cost model "instead calls
pgcolumnar_effective_stripe_row_limit()" as though that function were the
defect. It is not. One of its three callers is the writer, at
columnar_write_state.c:678, and there reading the session GUC is exactly
right: that call is deciding the geometry it is about to write. Only the two
planner sites are wrong.

So the fix is not to change that function. It is to give the planner a
different one and leave the writer's call alone.

Plan

1. pgcolumnar_written_stripe_row_limit(Oid relid) -- read
   storage.row_group_limit for the relation's storage. One row, one index
   lookup, comparable to the PgColumnarReadOptions call already made on this
   path. Falls back to the existing function when there is no storage row or the
   recorded value is not positive, which covers a table that has never been
   written.
   Verified by: a unit-shaped check that the new function returns 20000 for
   ga and 150000 for gb, against the catalog values above.

2. Switch the two planner call sites (columnar_customscan.c:1850 and
   :2185) and nothing else. columnar_write_state.c:678 stays.
   Verified by: the instrumented log above showing R=20000 n_groups=20 for
   ga, with gb unchanged at 150000/3 -- the control that says I changed the
   reader and not the writer.

3. A suite that fails without it. Plan-based, not clock-based, so
   PGC_SKIP_TIMING cannot drop it: the two tables have identical row counts and
   shapes and differ only in written geometry, so any cost or plan-choice
   assertion that distinguishes them is measuring exactly this.
   Verified by: running it on unmodified main and watching it redden.

4. Gate: full matrix on 18 and 19, five-major preflight on the branch,
   plus native_index_fetch_stripe_cost, scan_decode_cost, zonemap_cost
   and index_fetch_penalty_width, which are the suites that read this cost
   site.

The limitation I am not fixing, stated rather than hidden

storage.row_group_limit is one number, the last writer's. A table whose
groups were written under changing limits still gets a single approximate R.
That is strictly better than the reader's session GUC, which has nothing to do
with the table at all, and it is exact in the common case where a table is
written under one setting -- but it is not exact in general.

The exact answer is the real group count, N / count(row_group), and I am not
proposing it: that is a scan proportional to the number of groups, on every
plan, to refine a term that is already approximate. If someone wants it later it
wants a cached count, not a scan.

Starting on step 1. Speak up if the split between writer and planner is not how
you would draw it.

acting as: OffgridwithJD