MIME-Version: 1.0
References: <CA+TgmoZv8DvmeQHQAX+rkn68id2N+DoUhFZB36d-_w1tyAeqeA@mail.gmail.com>
 <CA+TgmobfeePej0uNfbLy0v6jUrB3D9m1Kh+QQ40_-A9KQjkqUw@mail.gmail.com>
 <f428e80d-8607-4a9d-950c-be9600f24904@gmail.com> <01ec86c1-e04b-4cbe-b641-22cae8b87604@tantorlabs.com>
 <CA+TgmobVWYnYDj1HZ--iqeKx+n7zTgtYCar+YfZ0V6wiX-t0Mg@mail.gmail.com>
 <73e2440e-7d8b-4860-974d-931a93326d95@gmail.com> <CA+Tgmoaob_3aNF5S49WFoJs6Rb37rNnd5WH_e9nXAn_jtWWCLQ@mail.gmail.com>
 <3737950.1740182671@sss.pgh.pa.us> <CA+TgmobXwtS0ncAVfukE-Uhhy8Zt5rQWwQb2WHBcSop8r4Lcgw@mail.gmail.com>
 <3816053.1740190267@sss.pgh.pa.us> <CA+TgmoZp7LstKmDwyfUuB+6aFFhn0N3fv2QxTD=dkrxXVJ5dZA@mail.gmail.com>
 <CA+TgmoazzVHn8sFOMFAEwoqBTDxKT45D7mvkyeHgqtoD2cn58Q@mail.gmail.com>
 <40663fc5-edac-4b45-a2aa-a76976700ed9@tantorlabs.com> <CA+TgmoZxRP8cEhfdF27k600B_=8DXpj=8kiM7s_6qCHCqxQPmA@mail.gmail.com>
 <CA+TgmoapgkOFmezwVjJbs5Xq9F+Mfm9aNouBgTq_AuqQJkLYEg@mail.gmail.com>
 <f61cb18b-0e51-4350-b122-f2557e02c487@tantorlabs.com> <e02b5ba8-d879-4121-a21e-8a3928be337e@postgrespro.ru>
In-Reply-To: <e02b5ba8-d879-4121-a21e-8a3928be337e@postgrespro.ru>
From: Matthias van de Meent <boekewurm+postgres@gmail.com>
Date: Thu, 6 Mar 2025 14:30:13 +0100
Message-ID: <CAEze2Wiap5v-H-5QqGq-=DBG99CK-RgHpQUFaU6TENh_+zCh_w@mail.gmail.com>
Subject: Re: explain analyze rows=%.0f
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>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAEze2Wiap5v-H-5QqGq-%3DDBG99CK-RgHpQUFaU6TENh_%2BzCh_w%40mail.gmail.com>
Precedence: bulk

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)