The carrier refresh costs 41 seconds per capture, and it is the producer CTE inlined per driving row

A capture of a consumer schema stops spending 41 seconds on the carrier relation and spends about 0.3 seconds instead, so a consumer whose schema reaches the carrier family gets most of a minute back on every build. Nothing about what the store answers changes: the same rows, in the same columns, under the same names every reader already spells.

The change is one materialization registration. A registration is a row in meta_materialize saying "refill this table from that view, once per capture, per graph": the view keeps the rule’s text under a _live name, the table takes the canonical name every reader spells, and so no reader is edited and the rule is still written exactly once. Which relation to register is the question the measurements below answer, and the answer is intent_field_payload_producer.

Measured against a real captured store for a consumer schema of 8408 fields, 2345 types, 5619 catalog columns and 39 classpath sources, one graph, using the same DELETE plus INSERT INTO target SELECT * FROM source_view WHERE graph_name = ? statements Materializations itself runs:

Materializations.analyse is 23 ms of that and is not worth attention. The store measured carried twelve registrations; the register has since grown, so the total is a floor rather than a current figure.

The children are all cheap, so there is nothing expensive underneath to reach for: intent_field_payload_producer is 4 to 31 ms, intent_bound_table 2 to 21 ms, intent_type_backing 3 to 15 ms, and intent_errors_field is a table and answers in under a millisecond.

Bisecting the body puts the cost in one place. The whole view is 45.7 s, the bare producer join data_channel with all three disqualification arms removed is 44.6 s, and the data_channel CTE evaluated on its own is 44.4 s. So the three NOT EXISTS arms together cost about 1.1 s and the CTE is the subject.

Inside that CTE the term is the population filter:

producer is a non-recursive WITH naming intent_field_payload_producer, and H2 inlines such a CTE exactly like a view with no common-subexpression elimination, so a correlated reference re-derives the whole rule once per driving row of graphql_field joined to graphql_type. The arithmetic closes: about 5 ms per evaluation against roughly eight thousand candidate rows is about forty seconds, against a measured 41.

Same store, same run, two sweeps each, OPTIMIZE_REUSE_RESULTS off:

The last row is the one worth keeping. The CTE also probes those two views inside a CASE WHEN EXISTS, which is where a reader following the plan’s shape would look first, and substituting tables for both changes nothing. Reading the body without pricing it would have named the wrong term.

Both candidate depths were measured on the same store:

The deeper option buys about 60 ms more and costs a new relation with a name and comments, so the shallower one is the registration to land and the difference belongs in the reason as measured follow-up rather than in this change.

The trade the middle rung has to win is a refresh against the re-evaluations it avoids, and here it is not close. One evaluation of intent_field_payload_producer is 4 to 31 ms. It has two readers in SQL: this correlated probe, and intent_field_error_channel, which drives from it in a plain FROM and therefore already pays exactly one evaluation and is indifferent to the registration.

All of it lands in graphitron-model/src/main/resources/no/sikt/graphitron/model/graphitron-model.sql, except one line of a test list and the re-pinned figures under "Tests and gates" below. It is the established cheap registration shape, so nothing here is a new mechanism.

Rename the rule’s view. CREATE VIEW intent_field_payload_producer becomes CREATE VIEW intent_field_payload_producer_live, column list and body unchanged, declared exactly where it stands today. Its inputs are graphitron_service, graphitron_mutation, graphitron_routine, graphql_field and graphql_root_operation, all captured base tables, so no declaration order in the file moves.

Declare the target under the canonical name, immediately after the view, which is the pair order the intent_errors_field_live / intent_errors_field pair a few relations above already uses:

Same column names in the same order as the view, which is what MaterializeRegistryGateTest.targetsAreShapedLikeTheViewsThatFillThem closes: the refresh is INSERT INTO target SELECT * FROM source, so a shape mismatch writes the wrong columns rather than failing. No primary key, because root_operation is meaningfully nullable and H2 refuses a key over a nullable column; that is why the index question below is a question at all rather than answered by the key.

Move the comments rather than write new ones. The relation’s existing view comment and its six column comments belong on the table, verbatim, with the standard materialization sentence appended to the relation comment:

The view then takes the stub form every other _live view carries, one relation comment naming where the documentation went and one per column:

Why the canonical name has to move to the table rather than the target taking a new one: readers and prose both. The two view bodies that read this relation are not edited, they simply stop hitting a view and start hitting a table, which is what makes a registration invisible. And SchemaIdentifierDriftCheck sweeps the DDL’s own comments for relation names and fails the build on one the store no longer declares, so the three citations in intent_field_error_channel’s comments (its view comment and its `transport and family column comments) stay true only because the name they spell is still declared. This change edits no prose outside the two relations it touches.

Register it. One row in INSERT INTO meta_materialize, keyed ('intent_field_payload_producer_live', 'intent_field_payload_producer', <reason>). The reason column is required and is where the argument lives, so this one has to state:

State facts and figures in that reason and do not cite a roadmap item id in it. The DDL’s prose is read by consumers through the generated schema reference, where an item id is stale the day the item ships.

Nothing orders the refresh by hand. meta_materialize_dependency is machine-written at boot by MaterializeDependencies.populate, which parses the stored view definitions, so the edge from intent_carrier_data_field_live to this registration appears on its own and the materializer refreshes the producer first. There is no authored row to add, and `MaterializeRegistryGateTest’s acyclicity and order-respecting tests are what confirm the edge arrived.

`intent_carrier_data_field_live’s registration prices its refresh at about 170 ms for 15 rows on the sakila example and about 12 ms on a carrier-free schema. The relation this item is about is the reason that figure does not transfer: on a consumer schema the same refresh is 41 s. The fact model page is explicit that a recorded measurement is evidence about the schema it was measured on and that a stored reason contradicted by a later measurement needs correcting where it lives, so the row should be corrected in the same change that moves the number, with both figures and the schema each was taken on.

Two sibling rows are wrong the same way and are deliberately out of scope here, because re-pricing the register’s recorded claims is R831’s subject rather than this item’s: intent_errors_field_live records about ten milliseconds against a measured 4.2 s, and intent_field_column_scope_live records about 170 ms "on a real schema" against a measured 6.4 s.

Every registered target either carries a declared index whose COMMENT ON INDEX names the reader it serves, or has a row in MaterializeRegistryGateTest.NO_INDEX arguing why not, asserted by equality in both directions. So this registration cannot land without answering the question, and the answer has to be a figure.

Do not assume the roster row. This is the first registration here whose motivating reader genuinely probes in from a population larger than the target: the carrier CTE’s EXISTS seeks (graph_name, payload_type_name) once per driving row of graphql_field joined to graphql_type, which is thousands of driving rows against a producer table of a few hundred. That is exactly the shape `intent_argument_column_match’s roster row names as the one that would change its own answer.

So declare and time ix_field_payload_producer_payload ON intent_field_payload_producer (graph_name, payload_type_name), on both the consumer store and the twelve-unit fixture DerivedReadCostTest runs, against no index at all. If it moves a reader, it ships with a comment naming that reader, on ix_spelled_table_spelling’s model. If it moves nothing, the relation joins `NO_INDEX with the figures that say so. The 327 ms and 261 ms refresh figures in this item were taken with no index declared, so they are the floor a roster row would stand on, and an index would have to earn its cost on every refresh on top of them.

No new behavioural test, and that is the mechanism working rather than a gap. A registration changes no answer, and the claim that the target holds its view’s rows is what the capture agreement machinery already asserts once the _live view is registered with it.

mvn install -Plocal-db from the repo root, on the exact tree that gets pushed. The agreement test and the read-cost gate both need the full pipeline, so a scoped -pl run is not verification for this item.

Separately from the build, re-take the two figures the reason will state, by the procedure in the store-performance skill: a store a real build already wrote rather than a fixture, single-file JDBC programs over the pinned H2 version, OPTIMIZE_REUSE_RESULTS off, the real refresh statements. Do not transcribe this item’s numbers into the DDL. They were measured on a tree whose register has grown since, and the register growing is exactly what moves them.

Why a registration can land with an unpriced refresh at all. DerivedReadCostTest holds the read side only, in scan counts, over a twelve-unit synthetic fixture, and states outright that it asserts no duration anywhere; MaterializeRegistryGateTest closes the register against the schema and asks nothing about cost. So nothing prices the side every consumer generate pays. That is an architectural question about what a registration must prove before it lands, it wants its own Spec cycle, and it is filed separately.

Every number above comes from the procedure in the store-performance skill, against a store a real build had already written rather than a fixture, driven from single-file JDBC programs over the H2 version the root pom pins. Nothing here was read off a reactor wall clock, a thread dump or a profiler frame. The relation timings are INFORMATION_SCHEMA.QUERY_STATISTICS rows or direct statement timings under OPTIMIZE_REUSE_RESULTS FALSE; the totals are the real refresh statements. The one figure taken at a single execution is the per-registration table in the first section, which ranks and is provisional in its tail; the 41 s subject was measured six times across four programs and ranged 39.7 s to 49.1 s, the high end taken while a second probe shared the machine.