Re: New IndexAM API controlling index vacuum strategies

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New IndexAM API controlling index vacuum strategies
Date: 2021-03-03 03:39:57
Message-ID: CAH2-Wz=co5LRAJsR1fDaWWzjK0ZbzApLRCHL1hNa1VPwRnhP_Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 2, 2021 at 6:44 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> A scale type parameter seems good to me but I wonder if how users can
> tune that parameter. We already have tuple-based parameters such as
> autovacuum_vacuum_scale_factor/threshold and I think that users
> basically don't pay attention to that table updates result in how many
> blocks.

Fair. The scale thing was just a random suggestion, nothing to take
too seriously.

> The third idea is a VACUUM command option like DISABLE_PAGE_SKIPPING
> to disable such skipping behavior. I imagine that the
> user-controllable-option to enforce both heap vacuum and index vacuum
> would be required also in the future when we have the vacuum strategy
> feature (i.g., incremental vacuum).

Yeah, I'm worried about conflicting requirements here -- this patch
and the next patch (that pushes the same ideas further) might have
different requirements.

I think that this patch will mostly be useful in cases where there are
very few LP_DEAD-containing heap pages, but consistently more than
zero. So it's probably not easy to tune.

What we might want is an on/off switch. But why? DISABLE_PAGE_SKIPPING
was added because the freeze map work in 9.6 was considered high risk
at the time, and we needed to have a tool to manage that risk. But
this patch doesn't seem nearly as tricky. No?

> > Lots of stuff in this area is kind of weird already. Sometimes this is
> > directly exposed to users, even. This came up recently, when I was
> > working on VACUUM VERBOSE stuff.

> That's true. I didn't know that.

It occurs to me that "tups_vacuumed vs. total LP_DEAD Items in heap
after VACUUM finishes" is similar to "pages_newly_deleted vs.
pages_deleted" for indexes. An easy mistake to make!

> > https://www.postgresql.org/message-id/flat/20130108024957.GA4751%40tornado.leadboat.com
> >
> > Of course, this effort to eliminate the "tupgone =
> > true"/XLOG_HEAP2_CLEANUP_INFO special case didn't go anywhere at the
> > time.
>
> I'll look at that thread.

I'm not sure if it's super valuable to look at the thread. But it is
reassuring to see that Noah shared the intuition that the "tupgone =
true" case was kind of bad, even back in 2013. It's one part of my
"mental map" of VACUUM.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-03-03 03:42:44 Re: repeated decoding of prepared transactions
Previous Message Amit Kapila 2021-03-03 03:36:11 Re: Track replica origin progress for Rollback Prepared