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

From Alena Rybakina
Subject Re: explain analyze rows=%.0f
Date
Msg-id e613eb22-015a-4fe8-8a08-142e41f7887d@postgrespro.ru
Whole thread Raw
In response to Re: explain analyze rows=%.0f  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
List pgsql-hackers
On 06.03.2025 16:30, Matthias van de Meent wrote:
> 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.
>
Thanks for the explanation. Now I understand.

-- 
Regards,
Alena Rybakina
Postgres Professional




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: what's going on with lapwing?
Next
From: Robert Haas
Date:
Subject: Re: making EXPLAIN extensible