Re: explain analyze rows=%.0f

Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>

From: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andrei Lepikhov <lepihov@gmail.com>, pgsql-hackers@lists.postgresql.org, Guillaume Lelarge <guillaume@lelarge.info>, Matheus Alcantara <matheusssilv97@gmail.com>, Alena Rybakina <a.rybakina@postgrespro.ru>
Date: 2025-02-28T12:27:16Z
Lists: pgsql-hackers
On 27.02.2025 19:51, Robert Haas wrote:
> On Mon, Feb 24, 2025 at 2:16 PM Robert Haas <robertmhaas@gmail.com> wrote:
>> On Mon, Feb 24, 2025 at 12:12 PM Ilia Evdokimov
>> <ilya.evdokimov@tantorlabs.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.




Commits

  1. EXPLAIN: Always use two fractional digits for row counts.

  2. Adjust EXPLAIN test case to filter out "Actual Rows" values.

  3. Allow EXPLAIN to indicate fractional rows.

  4. Fix pgbench performance issue induced by commit af35fe501.