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

From Peter Geoghegan
Subject Re: Nonrandom scanned_pages distorts pg_class.reltuples set by VACUUM
Date
Msg-id CAH2-Wzn5RtRU89+ZXyzjnGG6T60Nvf7yUtxe2SFRNE2EBmGqjg@mail.gmail.com
Whole thread Raw
In response to Re: Nonrandom scanned_pages distorts pg_class.reltuples set by VACUUM  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, Feb 17, 2022 at 1:36 PM Robert Haas <robertmhaas@gmail.com> wrote:
> > It's not that simple. As I said in the fix-up commit message, and in
> > the opening email to this thread, it basically isn't a new behavior at
> > all. It would be much more accurate to describe it as a behavior that
> > originated with commit e8429082, from late 2015. There was a subtle
> > interaction with that existing behavior, and the refactoring work,
> > that caused the reltuples problem.
>
> Honestly, I really think it's that simple. It really is possible to
> describe what changes a commit is making in the commit message -- and,
> in my opinion, you're not doing it.

The text of the commit message from commit e8429082 (Tom's 2015
commit) talks about "force examination of the table's last page...".
And on that basis I'm saying that I didn't invent the behavior
involving scanning the last page specifically -- which is clearly
true. I *did* overlook an issue that led to this nonrandom
scanned_pages bug, of course, but what should the take away be now?
What does that have to do with the commit message? The significance of
this oversight only became apparent after I committed the patch.

> > > 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 don't think it's fair to just suppose that much of what I write is
> > incomprehensible, just like that.
>
> I'm not supposing anything. I'm telling you what I can understand, and
> what I can't. Unless you intend to accuse me of pretending not to
> understand things that I actually do understand, I feel like my word
> on that topic should be treated as pretty much conclusive.

I'm not disputing that (how could I?). What I'm saying is that from my
perspective, the commit message of 44fa8488 was quite descriptive. I'm
certainly not asking you to agree with that, and I even think that the
fact that you disagree with it should be something that specifically
concerns me. But, there might be some specific instance in the future,
where you find some merit in the way I frame things, having first been
skeptical.

Doesn't that at least seem possible? And aren't you more or less
asking me to give you the same consideration? It's something to
consider -- that's all.

> I do think that you are doing some things right, for sure. But I don't
> think that you are following the community process particularly well.
> It doesn't really feel like you feel the need to convince other people
> that your changes are in good shape before committing them; and it is
> really hard for me to understand in detail what is being changed.

There is almost always ambiguity about these things, which I navigate
to the best of my ability, knowing that I will be judged in the future
based on my track record. It feels as if this discussion has been
muddied by the later work in the patch series, which really does make
pretty big, relatively risky changes to how we do certain things in
vacuumlazy.c. Maybe I shouldn't have referenced that work in the
commit message.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?
Next
From: Peter Geoghegan
Date:
Subject: Re: Nonrandom scanned_pages distorts pg_class.reltuples set by VACUUM