Re: Performance issues during pg_restore -j with big partitioned table
От | Adrian Klaver |
---|---|
Тема | Re: Performance issues during pg_restore -j with big partitioned table |
Дата | |
Msg-id | 7be2dcc6-3ba4-4e3f-a154-8d13d816aa9b@aklaver.com обсуждение исходный текст |
Ответ на | Re: Performance issues during pg_restore -j with big partitioned table (Adrian Klaver <adrian.klaver@aklaver.com>) |
Ответы |
Re: Performance issues during pg_restore -j with big partitioned table
|
Список | pgsql-general |
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. * * We mustn't do this for load-via-partition-root cases * because some data might get moved across partition * boundaries, risking deadlock and/or loss of previously * loaded data. (We assume that all partitions of a * partitioned table will be treated the same way.) > >> > >> >> Thanks in advance, >> Dimitris >> >> > -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: