mirror of
https://github.com/MBombeck/HealthLog.git
synced 2026-11-08 20:42:43 +00:00
Marc-André Bombeck
2b8eb2c1c2
The canonical-source pick grouped the window to (type, day, source), chose each day's source with DISTINCT ON, and joined the choices back to the rows. Whether that join ran as a hash join or as a nested loop that rescanned the whole pick for every row was the planner's call, made from table statistics. On a measurements table without them (a new install, or an import still under the autoanalyze threshold) it estimated one row on each side and took the nested loop. Binding the request's clock as a parameter instead of reading NOW() flipped which side of that loop the pick landed on: the analytics read over 6,000 freshly written blood-pressure rows went from 1.6 s to 8.4 s, and the demo seed's dashboard headline to 20 s. On a ten-year account without statistics the 90-day read took 4 s with either clock and the all-time read ran past two minutes. The pick is now one window function over one scan: FIRST_VALUE of the source per (type, UTC day) in ladder order, keeping the rows of that source. Same rows, same order of preference, so every day keeps its source; the parity suite against the DISTINCT ON statement holds that. The analytics read on the fixture above takes about 0.1 s, the headline 0.4 s. On the analysed ten-year account the 90-day and all-time reads are as fast as the join was, and they no longer depend on statistics. The rows carry one extra column, canonical_source; every reader selects its columns by name. A new integration test runs every reader shape under EXPLAIN ANALYZE on a table with no statistics and bounds the rows the plan produces or discards per row seeded. The statement count never moved, so a statement budget could not see this; the join measured 200 to 8,600 row visits per row seeded and the window stays at 4.