From: | Dimitrios Apostolou <jimis(at)gmx(dot)net> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Experience and feedback on pg_restore --data-only |
Date: | 2025-04-02 17:42:01 |
Message-ID: | 7e315548-805d-0c11-e143-acdcff8660e5@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi Laurenz,
On Sun, 23 Mar 2025, Laurenz Albe wrote:
> On Thu, 2025-03-20 at 23:48 +0100, Dimitrios Apostolou wrote:
>> Performance issues: (important as my db size is >5TB)
>>
>> * WAL writes: I didn't manage to avoid writing to the WAL, despite having
>> setting wal_level=minimal. I even wrote my own function to ALTER all
>> tables to UNLOGGED, but failed with "could not change table T to
>> unlogged because it references logged table". I'm out of ideas on this
>> one.
>
> You'd have to create an load the table in the same transaction, that is,
> you'd have to run pg_restore with --single-transaction.
Do you know why --single-transaction can't be combined with -j ?
I'm thinking it's because every process would need to have its own
transaction, which apparently results to more than one transaction.
Do you think this could be alleviated somehow with subtransactions?
I'm trying to think of a way to enjoy the performance benefits of
--single-transaction, while also parallelizing the pg_restore. For this
use case I don't care about the content appearing all in one transaction.
Would it be possible then to have dependency resolution in such a way that
we split the tasks into one transaction per worker process?
Just thinking out loud here, I'd be interested in feedback.
Thanks,
Dimitris
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2025-04-02 17:45:29 | Re: Performance issues during pg_restore -j with big partitioned table |
Previous Message | Adrian Klaver | 2025-04-02 17:39:36 | Re: Performance issues during pg_restore -j with big partitioned table |