Re: explain analyze rows=%.0f

On 27.02.2025 19:51, Robert Haas wrote:
> On Mon, Feb 24, 2025 at 2:16 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Mon, Feb 24, 2025 at 12:12 PM Ilia Evdokimov
>> <ilya(dot)evdokimov(at)tantorlabs(dot)com> wrote:
>>> If no one is concerned about rows being a non-integer, then I support
>>> this, as it's quite strange for the average rows to be an integer only
>>> for me. If we go with this approach, we should also update all examples
>>> in the documentation accordingly. I attached patch with changes in
>>> documentation.
>> Thanks, that's very helpful. If we go forward with this, I'll commit
>> your patch and mine together.
> Since Tom doesn't seem to want to further object to trying it this
> way, I've gone ahead and done this for now. Granted, it's not
> altogether clear from the buildfarm that we would have ever gotten any
> more failures after 44cbba9a7f51a3888d5087fc94b23614ba2b81f2, but it
> seems to me that there's no way to rule out the possibility, and
> low-frequency buildfarm failures that might only occur once a year are
> in some ways more annoying than high-frequency ones, especially to
> people who put a lot of energy into tracking down those failures. It
> just seems unprincipled to me to leave things in a state where we know
> that such failures are possible, and wonky to have things in a state
> where whether parallel query gets used or not could make the
> difference between getting a report of X rows and getting a report of
> X.00 rows. If a user notices that difference in their own environment
> -- regression tests aside -- they're not likely to guess what has
> happened.
>
> Of course, if this commit draws objections or runs into problems with
> the buildfarm or with users, we might have to reconsider. I'm not dead
> set on having it this way rather than any other. But I think it's more
> principled than making 0-vs-2 digits predicated on a random event; and
> it's a lot simpler than any of the other options that have been
> proposed.
>

Then I am moving the commitfest entry [0] to the Committed status.

[0]: https://commitfest.postgresql.org/patch/5501/

--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.