Horton

Re: why there is not VACUUM FULL CONCURRENTLY?

Nathan Bossart <nathandbossart@gmail.com>

View thread View on postgr.es
From: Nathan Bossart <nathandbossart@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Michael Banck <mbanck@gmx.net>, Antonin Houska <ah@cybertec.at>, 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>
Date: 2025-02-03T20:27:07Z
Lists: pgsql-hackers 
On Thu, Jan 30, 2025 at 04:29:35PM +0100, Alvaro Herrera wrote:
> 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.

+1

One small thing I thought of after the meeting was that this effectively
forces users to always specify an index if they want to REPACK WITH INDEX.
Today, CLUSTER will use the same index as before if one is not specified.
IMHO requiring users to specify the index is entirely reasonable, but I
figured I'd at least note the behavior change.

-- 
nathan

Commits

  1. Add CONCURRENTLY option to REPACK

  2. Introduce the REPACK command

  3. Adjust signature of cluster_rel() and its subroutines

  4. Simplify signature of RewriteTable