On Mon, Feb 24, 2025 at 2:16 PM Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Feb 24, 2025 at 12:12 PM Ilia Evdokimov > <ilya.evdoki...@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. -- Robert Haas EDB: http://www.enterprisedb.com
