On 17/2/2025 15:19, Robert Haas wrote:
> On Mon, Feb 17, 2025 at 3:08 AM Ilia Evdokimov
> if (nloops > 1)
>
> Instead of:
>
> if (nloops > 1 && rows_is_fractonal)
>
> I don't think it's really safe to just cast a double back to int64. In
> practice, the number of tuples should never be large enough to
> overflow int64, but if it did, this result would be nonsense. Also, if
> the double ever lost precision, the result would be nonsense. If we
> want to have an exact count of tuples, we ought to change ntuples and
> ntuples2 to be uint64. But I don't think we should do that in this
> patch, because that adds a whole bunch of new problems to worry about
> and might cause us to get nothing committed. Instead, I think we
> should just always show two decimal digits if there's more than one
> loop.
>
> That's simpler than what the patch currently does and avoids this
> problem. Perhaps it's objectionable for some other reason, but if so,
> can somebody please spell out what that reason is so we can talk about
> it?
I can understand two decimal places. You might be concerned about
potential issues with some codes that parse PostgreSQL explains.
However, I believe it would be beneficial to display fractional parts
only when iterations yield different numbers of tuples. Given that I
often work with enormous explains, I think this approach would enhance
the readability and comprehension of the output. Frequently, I may see
only part of the EXPLAIN on the screen. A floating-point row number
format may immediately give an idea about parameterisation (or another
reason for the subtree's variability) and trace it down to the source.
--
regards, Andrei Lepikhov
