The share of a tally's charged rows that is NOT explained by one row per statement.
This is not the index share, and it is not an upper bound on it either. An earlier docblock
here said it was, and the measurement falsified that: the recorded cold fill is 63 statements
against 12 charged rows, so explained clamps to 12 and this returns 0 for a fill that
scripts/measure/index-audit.ts decomposes as 9 of 12 rows index maintenance. A write path
with more no-op statements than rows will always read 0 here and look index-free.
What it does bound is the opposite direction -- rows that arrived from FEWER statements than rows,
which is a multi-row statement (INSERT ... SELECT, a DELETE clearing a bin) or a heavily
indexed insert. Useful for spotting a burst; useless for pricing an index. Use
splitChargedRows() with the schema's factors when the question is how much of a cost is index
maintenance.
The share of a tally's charged rows that is NOT explained by one row per statement.
This is not the index share, and it is not an upper bound on it either. An earlier docblock here said it was, and the measurement falsified that: the recorded cold fill is 63 statements against 12 charged rows, so
explainedclamps to 12 and this returns 0 for a fill thatscripts/measure/index-audit.tsdecomposes as 9 of 12 rows index maintenance. A write path with more no-op statements than rows will always read 0 here and look index-free.What it does bound is the opposite direction -- rows that arrived from FEWER statements than rows, which is a multi-row statement (
INSERT ... SELECT, aDELETEclearing a bin) or a heavily indexed insert. Useful for spotting a burst; useless for pricing an index. UsesplitChargedRows()with the schema's factors when the question is how much of a cost is index maintenance.