Re: Adding REPACK [concurrently]
| От | Alvaro Herrera |
|---|---|
| Тема | Re: Adding REPACK [concurrently] |
| Дата | |
| Msg-id | 202604062121.ijkompbo4ezj@alvherre.pgsql обсуждение исходный текст |
| Ответ на | Re: Adding REPACK [concurrently] (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: Adding REPACK [concurrently]
|
| Список | 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 по дате отправления: