public inbox for [email protected]
help / color / mirror / Atom feedFrom: Robert Haas <[email protected]>
To: Ilia Evdokimov <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Andrei Lepikhov <[email protected]>
Cc: [email protected]
Subject: Re: explain analyze rows=%.0f
Date: Thu, 27 Feb 2025 11:51:22 -0500
Message-ID: <CA+TgmoapgkOFmezwVjJbs5Xq9F+Mfm9aNouBgTq_AuqQJkLYEg@mail.gmail.com> (raw)
In-Reply-To: <CA+TgmoZxRP8cEhfdF27k600B_=8DXpj=8kiM7s_6qCHCqxQPmA@mail.gmail.com>
References: <CA+TgmoZv8DvmeQHQAX+rkn68id2N+DoUhFZB36d-_w1tyAeqeA@mail.gmail.com>
<CA+TgmobT9gPQLtw143oGnKVNtaOrTDOy+ZbLfe18MVZ9POjaWg@mail.gmail.com>
<[email protected]>
<[email protected]>
<CA+TgmoYzawdq40C5cN==LRPBvQChZ7t5XxH6wv+zMxnyM7LjBQ@mail.gmail.com>
<[email protected]>
<CA+TgmobfeePej0uNfbLy0v6jUrB3D9m1Kh+QQ40_-A9KQjkqUw@mail.gmail.com>
<[email protected]>
<[email protected]>
<CA+TgmobVWYnYDj1HZ--iqeKx+n7zTgtYCar+YfZ0V6wiX-t0Mg@mail.gmail.com>
<[email protected]>
<CA+Tgmoaob_3aNF5S49WFoJs6Rb37rNnd5WH_e9nXAn_jtWWCLQ@mail.gmail.com>
<[email protected]>
<CA+TgmobXwtS0ncAVfukE-Uhhy8Zt5rQWwQb2WHBcSop8r4Lcgw@mail.gmail.com>
<[email protected]>
<CA+TgmoZp7LstKmDwyfUuB+6aFFhn0N3fv2QxTD=dkrxXVJ5dZA@mail.gmail.com>
<CA+TgmoazzVHn8sFOMFAEwoqBTDxKT45D7mvkyeHgqtoD2cn58Q@mail.gmail.com>
<[email protected]>
<CA+TgmoZxRP8cEhfdF27k600B_=8DXpj=8kiM7s_6qCHCqxQPmA@mail.gmail.com>
On Mon, Feb 24, 2025 at 2:16 PM Robert Haas <[email protected]> wrote:
> On Mon, Feb 24, 2025 at 12:12 PM Ilia Evdokimov
> <[email protected]> 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.
--
Robert Haas
EDB: http://www.enterprisedb.com
view thread (38+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: explain analyze rows=%.0f
In-Reply-To: <CA+TgmoapgkOFmezwVjJbs5Xq9F+Mfm9aNouBgTq_AuqQJkLYEg@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox