Re: explain analyze rows=%.0f - Mailing list pgsql-hackers

From Matthias van de Meent
Subject Re: explain analyze rows=%.0f
Date
Msg-id CAEze2Wiap5v-H-5QqGq-=DBG99CK-RgHpQUFaU6TENh_+zCh_w@mail.gmail.com
Whole thread Raw
In response to Re: explain analyze rows=%.0f  (Alena Rybakina <a.rybakina@postgrespro.ru>)
Responses Re: explain analyze rows=%.0f
Re: explain analyze rows=%.0f
List 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)



pgsql-hackers by date:

Previous
From: Matheus Alcantara
Date:
Subject: Re: log_min_messages per backend type
Next
From: Andres Freund
Date:
Subject: Re: log_min_messages per backend type