Feedback-ID: ia2694551:Fastmail
Date: Mon, 6 Apr 2026 23:59:59 +0200
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Andres Freund <andres@anarazel.de>
Cc: Noah Misch <noah@leadboat.com>, vignesh C <vignesh21@gmail.com>,
	Antonin Houska <ah@cybertec.at>,
 Srinath Reddy Sadipiralla <srinath2133@gmail.com>,
	Amit Kapila <amit.kapila16@gmail.com>,
 Mihail Nikalayeu <mihailnikalayeu@gmail.com>,
	Matthias van de Meent <boekewurm+postgres@gmail.com>,
 Pg Hackers <pgsql-hackers@lists.postgresql.org>,
	Robert Treat <rob@xzilla.net>
Subject: Re: Adding REPACK [concurrently]
Message-ID: <202604062121.ijkompbo4ezj@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <pbqm52nsviwojptiszg2g6pqntbhnhaotbxshiysnensshnuv5@v6pmney4jror>
Archived-At: 
 <https://www.postgresql.org/message-id/202604062121.ijkompbo4ezj%40alvherre.pgsql>
Precedence: bulk

On 2026-Apr-06, Andres Freund wrote:

> I just saw this got committed and wanted to briefly play with it.  It works
> nicely!

Yeah, I have to say that Antonin did a great job here.

> Except that at first I tried this in a debugging build, and was briefly rather
> dismayed by the performance.  It was really slow.  But it's not really related
> to repack / the patches here.
>
> In that config, the assert single-handled increases the time for a repack by
> 35% or so.

Yeah, I saw it was kinda sluggish, but wow, I didn't see *that* much
overhead.

> It's totally valid to not have done so initially, this is a quite complicated
> feature:
> 
> I saw this is using individual heap_insert()s during the
> heapam_relation_copy_for_cluster().  Doing individual WAL logged inserts isn't
> exactly cheap or efficient from a WAL volume perspective...
> 
> Is there anything other than round tuits preventing us from using
> multi_insert?
> 
> That actually would also reduce the cost in the REPACK decoding worker, due to
> having to parse far fewer WAL records.

Nope, not really ... but I don't have any :-(

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