Re: Pg 16: will pg_dump & pg_restore be faster?
От | David Rowley |
---|---|
Тема | Re: Pg 16: will pg_dump & pg_restore be faster? |
Дата | |
Msg-id | CAApHDvoD-QsDzqKEMpG07dWU=5g1ZWSK_tjR5mC=a+79ZudddA@mail.gmail.com обсуждение исходный текст |
Ответ на | Pg 16: will pg_dump & pg_restore be faster? (Ron <ronljohnsonjr@gmail.com>) |
Ответы |
Re: Pg 16: will pg_dump & pg_restore be faster?
|
Список | pgsql-general |
On Wed, 31 May 2023 at 08:54, Ron <ronljohnsonjr@gmail.com> wrote: > https://www.postgresql.org/about/news/postgresql-16-beta-1-released-2643/ > says "PostgreSQL 16 can also improve the performance of concurrent bulk > loading of data using COPY up to 300%." > > Since pg_dump & pg_restore use COPY (or something very similar), will the > speed increase translate to higher speeds for those utilities? I think the improvements to relation extension only help when multiple backends need to extend the relation at the same time. pg_restore can have multiple workers, but the tasks that each worker performs are only divided as far as an entire table, i.e. 2 workers will never be working on the same table at the same time. So there is no concurrency in terms of 2 or more workers working on loading data into the same table at the same time. It might be an interesting project now that we have TidRange scans, to have pg_dump split larger tables into chunks so that they can be restored in parallel. David
В списке pgsql-general по дате отправления: