Re: explain analyze rows=%.0f - Mailing list pgsql-hackers

On Fri, Feb 21, 2025 at 9:11 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I apologize if I ruffled your feathers.  But the buildfarm is a shared
> resource and it doesn't do to leave it significantly broken over a
> weekend, which I feared you might be about to do.  Committing stuff
> at 4PM on a Friday is perhaps not the best plan if your intention
> is to not work weekends.

I really, really think we need some policy changes. Several committers
have told me that they literally won't commit anything on Friday for
fear of this exact kind of problem, but that means we lose a lot of
hours every week that people could potentially be dealing with patches
that have been waiting for an exceedingly long time for someone to
commit them. I feel like this is entirely a self-inflicted injury. We
could decide that CI is primary and the buildfarm is secondary, so
that as long as CI is green, you have a week to deal with anything
else that breaks. We could decide, as I said on the new thread I
started, to insist on having a vehicle for pre-commit buildfarm
testing. We could decide to just chill out over a couple of lines of
regression test diffs over a weekend where most people aren't going to
be working anyway. We could *at the very least* decide that you get 24
hours before you have to revert, perhaps with an exception if we're in
the last 14 days before feature freeze. There are probably other
things we could do. Yelling at people every time a patch turns the
buildfarm red for a few hours seems worse to me than MANY of the other
options.

Really, I feel like the way the buildfarm works is a relic of the
past. We're living in an era where cfbot is testing hundreds of
branches on a daily basis, all of which are completely untrusted code
downloaded from the Internet, but our buildfarm can't manage more than
about six and can't provide any testing resources even to committers.
In 2025, that's really far from the state of the art -- and CI seems
to be progressing a great deal faster than the BF, so the gap between
them figures to only get wider.

> On a positive note, at least some of the formerly-pink members
> seem to be happy now.  So as you hoped, we can get more info about
> whether there are less-frequent problems.

Cool.

> As for a permanent fix: maybe, instead of printing fractions when
> actual nloops > 1, we should print fractions if *potential*
> nloops > 1?  That is, anytime we're on the inside of a nestloop,
> under a Gather, etc.  Seems like this'd not be too hard to track
> while recursively descending the PlanState tree.

I guess we could do that, but how about just always displaying two
decimal places? I feel like you're really worried that people will be
confused if the row count is not an integer, but I'm not sure anyone
else has echoed that concern, and I am doubtful that it's really a
problem. Either people don't understand that the row count is divided
through by nloops, in which case the decimal places might actually
give them a clue that they've misunderstood, or they do understand
that, in which case the decimal places are not confusing. I feel like
we've gone to a lot of trouble to come up with complex solutions --
what was actually committed was one of the simpler things proposed --
but I am still not convinced that the simplest solution isn't for the
best.

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