Re: Nonrandom scanned_pages distorts pg_class.reltuples set by VACUUM - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Nonrandom scanned_pages distorts pg_class.reltuples set by VACUUM
Date
Msg-id CA+Tgmoa+O3v5T+B6-BmyG13czpQ3Mzx6L5Tbrj_jVuTgSv=-Ng@mail.gmail.com
Whole thread Raw
In response to Re: Nonrandom scanned_pages distorts pg_class.reltuples set by VACUUM  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Nonrandom scanned_pages distorts pg_class.reltuples set by VACUUM
Re: Nonrandom scanned_pages distorts pg_class.reltuples set by VACUUM
List pgsql-hackers
On Wed, Feb 16, 2022 at 10:43 PM Peter Geoghegan <pg@bowt.ie> wrote:
> How can you be surprised that I committed 44fa8488? It's essentially
> the same patch as the first version, posted November 22 -- almost 3
> months ago. And it's certainly not a big patch (though it is
> complicated).

Let's back up a minute and talk about the commit of $SUBJECT. The
commit message contains a Discussion link to this thread. This thread,
at the time you put that link in there, had exactly one post: from
you. That's not much of a discussion, although I do acknowledge that
sometimes we commit things that have bugs, and those bugs need to be
fixed even if nobody has responded.

That brings us to the question of whether 44fa8488 was improvidently
committed. I don't know the answer to that question, and here's why:

> The commit message is high level.

I would say it differently: I think the commit message does a poor job
describing what the commit actually does. For example, it says nothing
about changing VACUUM to always scan the last page of every heap
relation. This whole thread is about fixing a problem that was caused
by a significant behavior change that was *not even mentioned* in the
original commit message. If it had been mentioned, I likely would have
complained, because it's very similar to behavior that Tom eliminated
in b503da135ab0bdd97ac3d3f720c35854e084e525, which he did because it
was distorting reltuples estimates.

Commit messages need to describe what the commit actually changes.
Theoretical ideas are fine, but if I, as a committer who have done
significant work in this area in the past, can't read the commit
message and understand what is actually different, it's not a good
commit message. I think you *really* need to put more effort into
making your patches, and the emails about your patches, and the commit
messages for your patches understandable to other people. Otherwise,
waiting 3 months between when you post the patch and when you commit
it means nothing. You can wait 10 years to commit and still get
objections, if other people don't understand what you're doing.

I would guess that's really the root of Andres's concern here. I
believe that both Andres and I are in favor of the kinds of things you
want to do here *in principle*. But in practice I feel like it's not
working well, and thereby putting the project at risk. What if some
day one of us needs to fix a bug in your code? It's not like VACUUM is
some peripheral system where bugs aren't that critical -- and it's
also not the case that the risk of introducing new bugs is low.
Historically, it's anything but.

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



pgsql-hackers by date:

Previous
From: "Imseih (AWS), Sami"
Date:
Subject: Re: Add index scan progress to pg_stat_progress_vacuum
Next
From: Andrew Dunstan
Date:
Subject: Re: killing perl2host