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

From Matheus Alcantara
Subject Re: explain analyze rows=%.0f
Date
Msg-id CAFY6G8cQkCF4FryNpBDec8rjoAyQxVryfidd++5cgUE=JSAZqw@mail.gmail.com
Whole thread Raw
In response to Re: explain analyze rows=%.0f  (Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>)
List pgsql-hackers
Em seg., 10 de fev. de 2025 às 18:14, Ilia Evdokimov
<ilya.evdokimov@tantorlabs.com> escreveu:
> Sorry for missing your question earlier. If you notice in the code above, the variable(average) 'rows' is defined as:
>
> double rows = planstate->instrument->ntuples / nloops;
>
> This represents the total rows divided by the number of loops. The condition
> means that variable 'rows' will always  between zero and one. Therefore, the
> average rows under such conditions cannot be greater than or even equal to
> one. I wrote this condition specifically to avoid the verbose expression
> 'rows > 0 && rows < 1'. However, since this might not be obvious to everyone,
> perhaps it'd be better to write is using 'rows' directly or add a comment
> explaining this logic.
>
Thanks for the details! It makes sense to me now. I think that adding a comment
could be a good idea

> I agree with the last two points. As for the first one—maybe we could
> simply state that the average rows value can be decimal, especially for
> very small values?
>
> I'm just not sure about the "small values"; the 'rows' in decimal will only
> happen with small values? What would be a "small value" in this context? My main
> point here is more that I think that it would be good to mention *why* the
> 'rows' can be decimal, not just describe that it could be decimal.
>
>
> As for 'small values', it means that the average rows is between zero and
> one, to avoid rounding errors and misunderstanding. I think this would be
> ideal.
>
Get it, sounds reasonable to me.

--
Matheus Alcantara



pgsql-hackers by date:

Previous
From: Álvaro Herrera
Date:
Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation
Next
From: Tomas Vondra
Date:
Subject: Re: should we have a fast-path planning for OLTP starjoins?