Convert the page counts into range summaries and the mechanism stops being mysterious. With `pages_per_range=128`, each BRIN entry covers 128 consecutive heap blocks [3]. The fresh query read 1,536 heap pages, which is about twelve ranges [4][1]. After cumulative updates reached 5% of rows it read 51,268, which is roughly four hundred [9][1]. Assume the standard 8 kB block and the 976 MB heap holds about 124,928 blocks, or 976 ranges in total, so the query went from touching a bit over 1% of the table to 41% of it [2].
The damage is not proportional to churn. Five percent of 10 million rows is 500,000 updated rows, and between the 1% and 5% runs the count of matching ranges rose by roughly 386 [7]. One badly placed tuple is enough to stretch a range's minimum and maximum across the query's date boundary [13]. So 386 well-scattered relocations out of half a million updates would produce the whole result [7]. Sakamuri spent seven years in Oracle R&D and says he co-owned its Zonemaps module, which uses the same minimum and maximum values to decide which blocks a query can skip [15]. That background is what gives weight to his read on this failure: he is looking at a structure of the same kind he used to build.
The invisible constraint is free space. The updated column was not indexed [7], which is the case PostgreSQL can normally satisfy inside the page; the new tuple version lands elsewhere in the heap only when the original page has no room [13]. A bulk load in timestamp order [2] leaves pages with nothing spare. Meanwhile the global correlation statistic keeps measuring broad ordering between column and physical position, which is not what pruning depends on [12]. The catalog keeps reporting 48 kB throughout, a figure that stays accurate even as it stops describing anything useful about the index's behavior.
The two published times for the same 5% run differ by 132.8 milliseconds, about 24% [5]. That matters less for the 5% verdict than for the 20% one. The summary time at 20% churn, 690.6 ms [11], sits within a millisecond of the plan capture at 5%, while lossy pages over that interval rose 25% [6]. Read against the plan number, pruning is mostly finished by 5% and further churn buys little extra damage. That gap between the two figures is left open in the post [10], and it is the open question that decides which reading of the 20% number holds.
For the number to transfer you need several things true at once: a heap loaded in key order with no room on its pages, updates scattered across the key domain rather than piled at the newest end, a predicate narrow relative to the table (one day out of ninety here [2][3]), and a `pages_per_range` large enough that one poisoned range costs 128 page reads [3]. Concentrate the churn at the tail and the poisoned ranges are the ones your queries were already reading. Sakamuri says the run establishes a failure mode rather than a universal rule [17], and the post doubles as a demonstration for DeepSQL, his open-source self-hosted agent that reads slow queries and plans and recommends indexes [16]. The usable output is the monitoring target he names: watch lossy heap pages and rows discarded at recheck in the plan over time, because size and correlation will not tell you [18].
