MIME-Version: 1.0
References: <CA+TgmoZv8DvmeQHQAX+rkn68id2N+DoUhFZB36d-_w1tyAeqeA@mail.gmail.com>
 <CA+TgmobT9gPQLtw143oGnKVNtaOrTDOy+ZbLfe18MVZ9POjaWg@mail.gmail.com>
 <3365160.1739385615@sss.pgh.pa.us> <0e4c813a-18eb-41e2-8edb-89b78d43c82d@gmail.com>
 <CA+TgmoYzawdq40C5cN==LRPBvQChZ7t5XxH6wv+zMxnyM7LjBQ@mail.gmail.com>
 <e434311c-0f84-4c2b-a10d-ecb67f1ec19d@tantorlabs.com> <CA+TgmobfeePej0uNfbLy0v6jUrB3D9m1Kh+QQ40_-A9KQjkqUw@mail.gmail.com>
 <f428e80d-8607-4a9d-950c-be9600f24904@gmail.com> <01ec86c1-e04b-4cbe-b641-22cae8b87604@tantorlabs.com>
 <CA+TgmobVWYnYDj1HZ--iqeKx+n7zTgtYCar+YfZ0V6wiX-t0Mg@mail.gmail.com>
 <73e2440e-7d8b-4860-974d-931a93326d95@gmail.com> <CA+Tgmoaob_3aNF5S49WFoJs6Rb37rNnd5WH_e9nXAn_jtWWCLQ@mail.gmail.com>
 <3737950.1740182671@sss.pgh.pa.us> <CA+TgmobXwtS0ncAVfukE-Uhhy8Zt5rQWwQb2WHBcSop8r4Lcgw@mail.gmail.com>
 <3816053.1740190267@sss.pgh.pa.us> <CA+TgmoZp7LstKmDwyfUuB+6aFFhn0N3fv2QxTD=dkrxXVJ5dZA@mail.gmail.com>
 <CA+TgmoazzVHn8sFOMFAEwoqBTDxKT45D7mvkyeHgqtoD2cn58Q@mail.gmail.com>
 <40663fc5-edac-4b45-a2aa-a76976700ed9@tantorlabs.com> <CA+TgmoZxRP8cEhfdF27k600B_=8DXpj=8kiM7s_6qCHCqxQPmA@mail.gmail.com>
In-Reply-To: <CA+TgmoZxRP8cEhfdF27k600B_=8DXpj=8kiM7s_6qCHCqxQPmA@mail.gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Thu, 27 Feb 2025 11:51:22 -0500
Message-ID: <CA+TgmoapgkOFmezwVjJbs5Xq9F+Mfm9aNouBgTq_AuqQJkLYEg@mail.gmail.com>
Subject: Re: explain analyze rows=%.0f
To: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andrei Lepikhov <lepihov@gmail.com>, 
	pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CA%2BTgmoapgkOFmezwVjJbs5Xq9F%2BMfm9aNouBgTq_AuqQJkLYEg%40mail.gmail.com>
Precedence: bulk

On Mon, Feb 24, 2025 at 2:16=E2=80=AFPM Robert Haas <robertmhaas@gmail.com>=
 wrote:
> On Mon, Feb 24, 2025 at 12:12=E2=80=AFPM 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.

--=20
Robert Haas
EDB: http://www.enterprisedb.com