Thanks for the explanation around row tracking. I re-ran the samples that used EXPLAIN (ANALYZE, ...) and updated all examples to use (COSTS FALSE). I'm hoping it makes them less noisy.
Beyond that, I expanded a bit on how Hash and Hash Join nodes work in Postgres. Pre-rendered the new patch in Netlify to make it easier to peruse: - https://tubular-palmier-9a2fb3.netlify.app/planner-nodes Best, Brian B. On Fri, 31 Jul 2026 at 23:04, David Rowley <[email protected]> wrote: > On Sat, 1 Aug 2026 at 01:20, Brian Brennglass <[email protected]> wrote: > > Just as an aside, I am kind of curious why PG uses decimals to track > rows. Is it now possible to return half a row? > > It isn't. What the actual rows mean is the total rows returned divided > by the "loops" count. If loop 1 returns 2 rows and loop 2 gives you 3, > then that's 2.50 rows on average. Prior to that change, we'd have only > displayed "rows=2". For smaller average row counts, rounding down is > quite misleading, especially so when the average was below "1.0", > since we would have displayed "rows=0". The extra precision was added > to make that problem 100 times less bad. > > More details and links to mailing list discussion in [1]. > > David > > [1] > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=ddb17e387 >
v4-0001-doc-outline-all-planner-nodes.patch
Description: Binary data
