Re: VACUUM (DISABLE_PAGE_SKIPPING on)

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: VACUUM (DISABLE_PAGE_SKIPPING on)
Date: 2020-11-19 11:02:46
Message-ID: CANP8+jJgBii0PbzV5AxgCVMsBA1OVFGycEE3VTjEt8DWwSY4oA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 18 Nov 2020 at 17:59, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Wed, Nov 18, 2020 at 12:54 PM Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> > Patches attached.
> > 1. vacuum_anti_wraparound.v2.patch
> > 2. vacuumdb_anti_wrap.v1.patch - depends upon (1)
>
> I don't like the use of ANTI_WRAPAROUND as a name for this new option.
> Wouldn't it make more sense to call it AGGRESSIVE? Or maybe something
> else, but I dislike anti-wraparound.

-1 for using the term AGGRESSIVE, which seems likely to offend people.
I'm sure a more descriptive term exists.

> It's neither the most aggressive
> thing we can do to prevent wraparound (that's FREEZE),

The new option is not the same thing as the FREEZE option, as discussed above.

> nor is it the
> case that vacuums without this option (or indeed any options) can't
> help prevent wraparound, because the aggressive strategy may be
> chosen anyway.

Maybe.

The "aim [is] to move relfrozenxid forwards as quickly as possible" so
as to avoid wraparound, so having an unambiguous command that does
that is important for usability. It also allows us to rely on the
user's explicit intention to optimize vacuum towards that goal.

--
Simon Riggs http://www.EnterpriseDB.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-11-19 11:03:48 Re: Move OpenSSL random under USE_OPENSSL_RANDOM
Previous Message Craig Ringer 2020-11-19 10:40:19 Re: ResourceOwner refactoring