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
