Re: Performance issues during pg_restore -j with big partitioned table

On Wed, 2 Apr 2025, Adrian Klaver wrote:
>
>
> On 4/2/25 10:39 AM, Adrian Klaver wrote:
>>
>
>>  --clean will drop the object entirely not TRUNCATE.
>>
>>  I'm guessing that this is being done by you per:
>>
>>  https://www.postgresql.org/message-id/53760c70-4a87-a453-9e02-57abc9cb2e54%40gmx.net
>>
>>  "After each failed attempt, I need to issue a TRUNCATE table1,table2,...
>>  before I try again. "
>
> Oops, forgot to engage brain.
>
> From pg_backup_archiver.c:
>
> * In parallel restore, if we created the table earlier in
> * this run (so that we know it is empty) and we are not
> * restoring a load-via-partition-root data item then we
> * wrap the COPY in a transaction and precede it with a
> * TRUNCATE.  If wal_level is set to minimal this prevents
> * WAL-logging the COPY.  This obtains a speedup similar
> * to that from using single_txn mode in non-parallel
> * restores.

This makes sense. It creates the table earlier, and then truncates it just
before copying data into it. I wonder if this really circumvents the WAL
since I don't have --single-transaction  (incompatible to -j).


Dimitris