From: Antonin Houska <ah@cybertec.at>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
cc: 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: <202501091335.pn54a2ettbsi@alvherre.pgsql>
References: <202501091335.pn54a2ettbsi@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@alvh.no-ip.org>
   message dated "Thu, 09 Jan 2025 14:35:42 +0100."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <10816.1736443562.1@antos>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 09 Jan 2025 18:26:02 +0100
Message-ID: <10818.1736443562@antos>
Archived-At: <https://www.postgresql.org/message-id/10818.1736443562%40antos>
Precedence: bulk

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

> On 2024-Dec-11, Antonin Houska wrote:
> =

> > Oh, it was too messy. I think I was thinking of too many things at onc=
e (such
> > as locking the old heap, the new heap and the new heap's TOAST). Also,=
 one
> > thing that might have contributed to the confusion is that make_new_he=
ap() has
> > the 'lockmode' argument, which receives various values from various
> > callers. However, both the new heap and its TOAST relation are eventua=
lly
> > created by heap_create_with_catalog(), and this function always leaves=
 the new
> > relation locked in AccessExclusiveMode. Maybe this needs some refactor=
ing.
> > =

> > Therefore I reverted the changes arount make_new_heap() and simply pas=
s NoLock
> > for lockmode in cluster.c
> =

> Cool, thanks, I have pushed this.  I made some additional minor changes,
> nothing earth-shattering.

It seems you accidentally fixed another problem :-) I was referring to the
'lockmode' argument of make_new_heap(). I can try to write a patch for tha=
t
but ...

> Meanwhile the patch 0004 has some seemingly trivial conflicts.  If you
> want to rebase, I'd appreciate that.  In the meantime I'll give a look
> at the next two other API changes.

... I can apply v06 even though I do have the commit ebd8fc7e47 in my work=
ing
tree. (And the CF bot does not complain (yet?).) Have you removed the
'lockmode' argument also from make_new_heap() and forgot to push it? This
change would probably cause a conflict with v06.

> I'm not happy with the idea of having this new command be VACUUM (FULL
> CONCURRENTLY).  It's a bit of an absurd name if you ask me.  Heck, even
> VACUUM (FULL) seems a bit absurd nowadays.
> =

> Maybe we should have a new toplevel command.  Some ideas that have been
> thrown around:
> =

> - RETABLE (it's like REINDEX, but for tables)
> - ALTER TABLE <tab> SQUEEZE
> - SQUEEZE <table>
> - VACUUM (SQUEEZE)
> - VACUUM (COMPACT)
> - MAINTAIN <tab> COMPACT
> - MAINTAIN <tab> SQUEEZE

I recall that DB2 has REORG command, which also can do clustering [1]

Regardless the name of the new command, should that also handle the
non-concurrent cases? In that case we'd probably need to mark CLUSTER and
VACUUM (FULL) as deprecated.

[1] https://www.ibm.com/docs/en/db2/12.1?topic=3Dcommands-reorg-table

-- =

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