Horton

Re: explain analyze rows=%.0f

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Alena Rybakina <a.rybakina@postgrespro.ru>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>, Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>, Tom Lane <tgl@sss.pgh.pa.us>, Andrei Lepikhov <lepihov@gmail.com>, pgsql-hackers@lists.postgresql.org, Guillaume Lelarge <guillaume@lelarge.info>, Matheus Alcantara <matheusssilv97@gmail.com>
Date: 2025-03-06T23:32:06Z
Lists: pgsql-hackers 
On Thu, Mar 6, 2025 at 4:18 PM Alena Rybakina <a.rybakina@postgrespro.ru> wrote:
> To be honest, I initially took it as the total number of tuples and
> couldn't figure out for myself how to interpret the result - 0 tuples or
> 1 tuple in the end. Maybe it wasn't quite correct to perceive it that
> way, but Matthias's explanation helped me figure out the reason why such
> a strange result was obtained, although it's not usual to see it.

Yeah, I thought the same back when I first started using PostgreSQL
and had to learn that it wasn't the case. I still think that's what we
*should* be displaying -- I think dividing by nloops obscures the data
users actually want. But it would admittedly be a pretty big
compatibility break at this point, and at least if we display a couple
of decimal places it's more possible to approximate the undivided
value.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

Commits

  1. EXPLAIN: Always use two fractional digits for row counts.

  2. Adjust EXPLAIN test case to filter out "Actual Rows" values.

  3. Allow EXPLAIN to indicate fractional rows.

  4. Fix pgbench performance issue induced by commit af35fe501.