Message-ID: <f61cb18b-0e51-4350-b122-f2557e02c487@tantorlabs.com>
Date: Fri, 28 Feb 2025 15:27:16 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: explain analyze rows=%.0f
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>
References: <CA+TgmoZv8DvmeQHQAX+rkn68id2N+DoUhFZB36d-_w1tyAeqeA@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>
 <CA+TgmoapgkOFmezwVjJbs5Xq9F+Mfm9aNouBgTq_AuqQJkLYEg@mail.gmail.com>
Content-Language: en-US
From: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>
In-Reply-To: <CA+TgmoapgkOFmezwVjJbs5Xq9F+Mfm9aNouBgTq_AuqQJkLYEg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/f61cb18b-0e51-4350-b122-f2557e02c487%40tantorlabs.com>
Precedence: bulk


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.