Re: explain analyze rows=%.0f
От | Andrei Lepikhov |
---|---|
Тема | Re: explain analyze rows=%.0f |
Дата | |
Msg-id | e75ab0ca-2e52-462d-8fcc-35f7d3e86877@gmail.com обсуждение исходный текст |
Ответ на | Re: explain analyze rows=%.0f (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: explain analyze rows=%.0f
|
Список | pgsql-hackers |
On 8/2/2025 04:28, Ilia Evdokimov wrote: > On 08.02.2025 00:01, Matheus Alcantara wrote: >> Just for reference I'm trying to apply based on commit fb056564ec5. > You are right, because two commits were appeared after creating v6-patch > on partition_prune.out and patch v6 must not have applied on master. > Then I created v7 patch rebased on fb056564ec5 . Thank for your remark! I support the idea in general, but I believe it should be expanded to cover all cases of parameterised plan nodes. Each rescan iteration may produce a different number of tuples, and rounding can obscure important data. For example, consider five loops of a scan node: the first loop returns nine tuples, and each other - zero tuples. When we calculate the average, 9 divided by 5 equals 1.8. This results in an explanation that indicates "rows = 1," masking almost 40% of the data. Now, if we apply the same two loops but have a total of 900,000 tuples, then 400,000 masked tuples represent a significant portion of the data. Moreover, switching to a floating-point type for row explanations in each parameterised node would provide a more comprehensive view and add valuable information about the parameterisation of the node, which may not be immediately apparent. -- regards, Andrei Lepikhov
В списке pgsql-hackers по дате отправления: