Re: Adding REPACK [concurrently] - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Adding REPACK [concurrently]
Date
Msg-id 202604062121.ijkompbo4ezj@alvherre.pgsql
Whole thread Raw
In response to Re: Adding REPACK [concurrently]  (Andres Freund <andres@anarazel.de>)
Responses Re: Adding REPACK [concurrently]
List pgsql-hackers
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/



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Add pg_stat_autovacuum_priority
Next
From: Jacob Champion
Date:
Subject: Re: DEREF_AFTER_NULL: src/common/jsonapi.c:2529