Re: explain analyze rows=%.0f

Matthias van de Meent <boekewurm+postgres@gmail.com>

From: Matthias van de Meent <boekewurm+postgres@gmail.com>
To: Alena Rybakina <a.rybakina@postgrespro.ru>
Cc: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>, Robert Haas <robertmhaas@gmail.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-06T13:30:13Z
Lists: pgsql-hackers
On Thu, 6 Mar 2025 at 14:18, Alena Rybakina <a.rybakina@postgrespro.ru> wrote:
>
> Hi! I got a query plan with a strange number of rows. Could you please
> help me understand it?
>
> To be honest I can't understand why 0.50 number of rows here?

Because the scan matched only ~(500 rows over 999 iterations = 500/999
~=) 0.50 rows for every loop, on average, for these plan nodes:

>             ->  Nested Loop (actual rows=0.50 loops=999)
>                   ->  Seq Scan on tb (actual rows=0.50 loops=999)

And for this, it was 500 rows total in 1000 iterations, which also
rounds to 0.50:

>     SubPlan 2
>       ->  Result (actual rows=0.50 loops=1000)
>             One-Time Filter: ((ta1.id < 1000) AND (InitPlan 1).col1)

As of ddb17e38 (and its follow-up 95dbd827), we display fractional
rows-per-loop, with 2 digits of precision, rather than a rounded
integer. This allows a user to distinguish plan nodes with 0.49
rows/loop and 0.01 rows/loop, and that can help inform the user about
how to further optimize their usage of indexes and other optimization
paths.

Kind regards,

Matthias van de Meent
Neon (https://neon.tech)



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.