Re: explain analyze rows=%.0f
От | Ilia Evdokimov |
---|---|
Тема | Re: explain analyze rows=%.0f |
Дата | |
Msg-id | f61cb18b-0e51-4350-b122-f2557e02c487@tantorlabs.com обсуждение исходный текст |
Ответ на | Re: explain analyze rows=%.0f (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: explain analyze rows=%.0f
|
Список | 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.
В списке pgsql-hackers по дате отправления: