From: Antonin Houska <ah@cybertec.at>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
cc: Srinath Reddy Sadipiralla <srinath2133@gmail.com>,
    Matthias van de Meent <boekewurm+postgres@gmail.com>,
    Mihail Nikalayeu <mihailnikalayeu@gmail.com>,
    Pg Hackers <pgsql-hackers@lists.postgresql.org>,
    Robert Treat <rob@xzilla.net>
Subject: Re: Adding REPACK [concurrently]
In-reply-to: <202603200752.zigubezzfcql@alvherre.pgsql>
References: <202603200752.zigubezzfcql@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@alvh.no-ip.org>
   message dated "Fri, 20 Mar 2026 08:59:23 +0100."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <12104.1774261203.1@localhost>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 23 Mar 2026 11:20:03 +0100
Message-ID: <12105.1774261203@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/12105.1774261203%40localhost>
Precedence: bulk

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

> On 2026-Mar-19, Antonin Houska wrote:
> =

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

> > > So here's v43.  Here, I've changed the CONCURRENTLY implementation t=
o go
> > > through table AM.  This necessitated changing it to use tuples in sl=
ots
> > > instead of HeapTuple.  This is good because we can avoid repeated tu=
ple
> > > form/deform, which could get pretty expensive.  Antonin's 0004 patch
> > > here looks suspicious here though, because it deforms the tuple and
> > > forms it again, which sounds unnecessary now.
> > =

> > I suppose you mean
> > v42-0004-Serialize-decoded-tuples-without-flattening.patch. This defor=
ms the
> > tuple to get the external attributes and to write them to file. The tu=
ple the
> > logical worker received from reorderbuffer.c cannot be passed to the b=
ackend
> > executing REPACK because it may contain "external indirect" attributes=
,
> > i.e. pointers to the worker's memory.
> =

> No, that patch has been absorbed in what is now v43-0003.  I meant
> v43-0004 "Use BulkInsertState when copying data to the new heap.",
> that's why I said "patch 0004 here".  In this patch, we have
> reform_tuple which deforms the tuple, sets to NULL any attribute that's
> marked dropped, and then forms a new one.  This is wasteful and should
> probably be done elsewhere, while the tuple is still in slot
> representation.  In fact, I suspect it may not be necessary at all
> anymore.

The idea to "reform" the tuple comes from VACUUM FULL / CLUSTER. I agree t=
he
"deform" and "form" steps are no longer needed when we use tuple slots.

-- =

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