agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedFrom: Antonin Houska <ah@cybertec.at>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Marcos Pegoraro <marcos@f10.com.br>
Cc: Michael Banck <mbanck@gmx.net>
Cc: Junwang Zhao <zhjwpku@gmail.com>
Cc: Kirill Reshke <reshkekirill@gmail.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: why there is not VACUUM FULL CONCURRENTLY?
Date: Fri, 04 Apr 2025 12:28:36 +0200
Message-ID: <13028.1743762516@localhost> (raw)
In-Reply-To: <202504040733.ysuy5gad55md@alvherre.pgsql>
References: <202504040733.ysuy5gad55md@alvherre.pgsql>
Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> 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.
ok, I'll adjust the patch set.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
view thread (88+ messages) latest in thread
Message-ID: <13028.1743762516@localhost>
Permalink: ../13028.1743762516@localhost/
Also on: postgresql.org/message-id/13028.1743762516@localhost
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: ah@cybertec.at, alvherre@alvh.no-ip.org, marcos@f10.com.br, mbanck@gmx.net, zhjwpku@gmail.com, reshkekirill@gmail.com, pavel.stehule@gmail.com, michael@paquier.xyz
Subject: Re: why there is not VACUUM FULL CONCURRENTLY?
In-Reply-To: <13028.1743762516@localhost>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox