Feedback-ID: ia2694551:Fastmail
Date: Thu, 9 Jan 2025 14:35:42 +0100
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Antonin Houska <ah@cybertec.at>
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?
Message-ID: <202501091335.pn54a2ettbsi@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <47194.1733941797@antos>
Archived-At: 
 <https://www.postgresql.org/message-id/202501091335.pn54a2ettbsi%40alvherre.pgsql>
Precedence: bulk

On 2024-Dec-11, Antonin Houska wrote:

> Oh, it was too messy. I think I was thinking of too many things at once (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_heap() has
> the 'lockmode' argument, which receives various values from various
> callers. However, both the new heap and its TOAST relation are eventually
> created by heap_create_with_catalog(), and this function always leaves the new
> relation locked in AccessExclusiveMode. Maybe this needs some refactoring.
> 
> Therefore I reverted the changes arount make_new_heap() and simply pass NoLock
> for lockmode in cluster.c

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

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'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

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/