pub const EDGES: usize = 90;Expand description
Edge assertions (bulk_import).
Per-row cost on this path rises with the size of links_current, not
with the chunk (D-059) — so cutting the chunk buys latency and costs
throughput, ~11% for 1,000 edges. An earlier version of this comment
claimed it was 3.3× faster; that came from multiplying eleven copies of
a chunk measured into an empty database.
This size does not meet the 3 ms bound on a populated database. 90 edges into an 8,000-edge table take 9.06 ms — measured, two sessions at 9.08 and 9.05, against an empty-table arm of 2.69 and 2.65 beside them (D-136).
The reason given here until 0.10.0 — that trg_links_single_open’s
EXISTS scans the whole out-degree, “a schema defect with a proven fix,
recorded in D-059 and not applied here” — described 0.5.5. The fix was
applied, as the v5 → v6 rung, and took this from 47.7 ms to ~8 ms.
What survives is the miss: the bound is still exceeded ~3×. Its cause is
no longer unknown — D-142 attributes it to trg_links_current_sync, and
within that to secondary-index maintenance on links_current — and the
guard this comment used to blame contributes no growth at all.
The constant is unchanged, and that is now a measured decision
(D-143). Re-derived against all four D-088 shapes at 8,000 edges, they
agree that the largest size meeting the bound is 20. It stays at 90
because 20 is the same miss at a larger population — per-row cost grows
with links_current, so a constant fitted at 8,000 edges is wrong at
80,000 — while the throughput cost of turning eleven chunks into fifty
is certain and immediate (D-058). The fix is not a row count: it is for
the chunk loop to stop on elapsed time, delivered in 0.12.0. This
number is now the ceiling that loop starts from and never exceeds; on a
populated table it converges below it within a chunk or two.
D-134 retired the growth claim on the neighbouring single-assertion path and did not measure this one; D-136 is why this line now carries a measurement rather than a figure quoted from 0.5.6.