Horton

Re: explain analyze rows=%.0f

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>, Matthias van de Meent <boekewurm+postgres@gmail.com>, Andrei Lepikhov <lepihov@gmail.com>, pgsql-hackers@lists.postgresql.org, Guillaume Lelarge <guillaume@lelarge.info>, Matheus Alcantara <matheusssilv97@gmail.com>, Alena Rybakina <a.rybakina@postgrespro.ru>
Date: 2025-03-31T19:09:24Z
Lists: pgsql-hackers 
On Mon, Mar 31, 2025 at 1:49 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > But why isn't it just as valuable to have two decimal places for the
> > estimate? I theorize that the cases that are really a problem here are
> > those where the row count estimate is between 0 and 1 per row, and
> > rounding to an integer loses all precision.
>
> Currently, the planner rounds *all* rowcount estimates to integers
> (cf. clamp_row_est()).  Maybe it'd be appropriate to rethink that,
> but it's not just a matter of changing EXPLAIN's print format.

Oh, right. I've never really understood why we round off to integers,
but the fact that we don't allow row counts < 1 feels like something
pretty important. My intuition is that it probably helps a lot more
than it hurts, too.

-- 
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.