Re: do only critical work during single-user vacuum? - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: do only critical work during single-user vacuum?
Date
Msg-id CAD21AoBXPxmCowqauR4DLU8zVNrbngewbQOQuXqJF89chQa=Zg@mail.gmail.com
Whole thread Raw
In response to Re: do only critical work during single-user vacuum?  (John Naylor <john.naylor@enterprisedb.com>)
Responses Re: do only critical work during single-user vacuum?
List pgsql-hackers
On Thu, Jan 20, 2022 at 4:14 AM John Naylor
<john.naylor@enterprisedb.com> wrote:
>
> On Wed, Jan 19, 2022 at 12:46 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > On Fri, Jan 14, 2022 at 7:04 AM Bossart, Nathan <bossartn@amazon.com> wrote:
> > >
> > > I guess I'm ultimately imagining the new options as replacing the
> > > vacuumdb implementation.  IOW vacuumdb would just use MIN_(M)XID_AGE
> > > behind the scenes (as would a new top-level command).
> >
> > I had the same idea.
>
> This seems to be the motivating reason for wanting new configurability
> on the server side. In any case, new knobs are out of scope for this
> thread. If the use case is compelling enough, may I suggest starting a
> new thread?

The purpose of this thread is to provide a way for users to run vacuum
only very old tables (while skipping index cleanup, etc.), and the way
is not limited to introducing a new top-level VACUUM statement yet,
right? A new top-level VACUUM statement you proposed seems a good idea
but trying to achieve it by extending the current VACUUM statement is
also a good idea. So I think the ideas like MIN_XID_AGE option and new
table selector in VACUUM statement are relevant to this thread.

Regards,

-- 
Masahiko Sawada
EDB:  https://www.enterprisedb.com/



pgsql-hackers by date:

Previous
From: Greg Nancarrow
Date:
Subject: Re: Skipping logical replication transactions on subscriber side
Next
From: "kuroda.hayato@fujitsu.com"
Date:
Subject: RE: [Proposal] Add foreign-server health checks infrastructure