From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Ron <ronljohnsonjr(at)gmail(dot)com> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Pg 16: will pg_dump & pg_restore be faster? |
Date: | 2023-05-30 21:14:20 |
Message-ID: | CAApHDvoD-QsDzqKEMpG07dWU=5g1ZWSK_tjR5mC=a+79ZudddA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, 31 May 2023 at 08:54, Ron <ronljohnsonjr(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Wienhold | 2023-05-30 21:42:37 | Re: event trigger should provide more details |
Previous Message | Ron | 2023-05-30 20:54:11 | Pg 16: will pg_dump & pg_restore be faster? |