From: Antonin Houska <ah@cybertec.at>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
cc: Michael Banck <mbanck@gmx.net>, Junwang Zhao <zhjwpku@gmail.com>,
    Kirill Reshke <reshkekirill@gmail.com>,
    Pavel Stehule <pavel.stehule@gmail.com>,
    Michael Paquier <michael@paquier.xyz>,
    PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: why there is not VACUUM FULL CONCURRENTLY?
In-reply-to: <202501301529.ejggbtao2skr@alvherre.pgsql>
References: <202501301529.ejggbtao2skr@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@alvh.no-ip.org>
   message dated "Thu, 30 Jan 2025 16:29:35 +0100."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <10747.1738304870.1@antos>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 31 Jan 2025 07:27:50 +0100
Message-ID: <10749.1738304870@antos>
Archived-At: <https://www.postgresql.org/message-id/10749.1738304870%40antos>
Precedence: bulk

Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:

> On 2025-Jan-30, Michael Banck wrote:
> =

> > > I haven't addressed the problem of a new command yet - for that I'd =
like to
> > > see some sort of consensus, so that I do not have to do all the rela=
ted
> > > changes many times.
> > =

> > Well, looks like this patch-set is blocked on the bikeshedding part?
> > =

> > Somebody should call a shot here, then.
> =

> A bunch of people discussed this patch in today's developer meeting in
> Brussels.  There's pretty much a consensus on using the verb REPACK
> CONCURRENTLY for this new command -- where unadorned REPACK would be
> VACUUM FULL, and we'd have something like REPACK WITH INDEX or maybe
> REPACK USING INDEX to take the CLUSTER place.

Thanks for discussing the patch.

I assume the patch should mark CLUSTER deprecated rather than removing it
immediately.

> For the record, there was an observation that 1) if logical decoding is
> not enabled, REPACK CONCURRENTLY would not work, and 2) that sites being
> forced to enable logical decoding (even if transiently) to allow this,
> might take a considerable performance hit, and that we shouldn't
> entangle our features in that way.  I don't have an opinion on these
> things at this point; knowing more about exactly what the performance
> impact is would be good.  Regarding logical decoding, the conversation
> continued that maybe it'd be good if the feature can be automatically
> enabled transiently for that particular table for as long as needed, and
> disabled afterwards.  But like with the previous concern, I don't really
> have an opinion without understanding it more deeply.

Enabling the logical decoding transiently makes sense to me.

I also agree that tables not being REPACKed should be treated as not being
logically decoded, i.e. the logical decoding specific information should n=
ot
be written to WAL for them. Neither time nor energy should be wasted :-)

I'll try to implement these requirements the next version.

-- =

Antonin Houska
Web: https://www.cybertec-postgresql.com