Re: explain analyze rows=%.0f
От | Alena Rybakina |
---|---|
Тема | Re: explain analyze rows=%.0f |
Дата | |
Msg-id | e613eb22-015a-4fe8-8a08-142e41f7887d@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: explain analyze rows=%.0f (Matthias van de Meent <boekewurm+postgres@gmail.com>) |
Список | 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 по дате отправления: