Feedback-ID: ia2694551:Fastmail
Date: Fri, 4 Apr 2025 09:33:54 +0200
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Antonin Houska <ah@cybertec.at>
Cc: Marcos Pegoraro <marcos@f10.com.br>, 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?
Message-ID: <202504040733.ysuy5gad55md@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <178741.1743514291@localhost>
Archived-At: <https://www.postgresql.org/message-id/202504040733.ysuy5gad55md%40alvherre.pgsql>
Precedence: bulk

On 2025-Apr-01, Antonin Houska wrote:

> Besides that, it occurred to me that 0005 ("Preserve visibility
> information of the concurrent data changes.") will probably introduce
> significant overhead. The problem is that the table we're repacking is
> treated like a catalog, for reorderbuffer.c to generate snapshots that
> we need to replay UPDATE / DELETE commands on the new table.
> 
> contrib/test_decoding can be used to demonstrate the difference
> between ordinary and catalog tables:
> 
> [.. ordinary ..]
> Execution Time: 3521.190 ms
> [.. catalog ..]
> Execution Time: 6561.634 ms

Significant indeed.  Thinking about the scenarios in which I envision
people using REPACK CONCURRENTLY (mostly, cases where very large tables
have accumulated considerable amounts of bloat) and considering the size
of the patch, I think the case for treating it as concurrent-safe is not
credible, at least not at this stage -- not only because of this
performance impact, but also because of the additional code complexity,
which I'm really doubtful we can address at this stage.  I would suggest
to put that patch aside for now, maybe with a doc warning that
"repacking a table would cause visibility information to be lost"; and
then address that aspect later on, after this feature has gone through
some battle-hardening.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"Las navajas y los monos deben estar siempre distantes"   (Germán Poo)