Re: Pg 16: will pg_dump & pg_restore be faster?

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>, "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
Cc: Ron <ronljohnsonjr(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: Pg 16: will pg_dump & pg_restore be faster?
Date: 2023-05-31 02:05:10
Message-ID: CAApHDvrQ1bpzyS8k=nHsL0rNFNOkiGmiJRQGO4jUb4yPS4EysQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, 31 May 2023 at 13:13, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> There is no mention of concurrency being a requirement. Is it wrong? I
> think there was a question of whether you had to add _multiple_ blocks
> ot get a benefit, not if concurrency was needed. This email about the
> release notes didn't mention the concurrent requirement:

My understanding had been that concurrency was required, but I see the
commit message for 00d1e02be mentions:

> Even single threaded
> COPY is measurably faster, primarily due to not dirtying pages while
> extending, if supported by the operating system (see commit 4d330a61bb1).

If that's the case then maybe the beta release notes could be edited
slightly to reflect this. Maybe something like:

"Relation extensions have been improved allowing faster bulk loading
of data using COPY. These improvements are more significant when
multiple processes are concurrently loading data into the same table."

The current text of "PostgreSQL 16 can also improve the performance of
concurrent bulk loading of data using COPY up to 300%." does lead me
to believe that nothing has been done to improve things when only a
single backend is involved.

David

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2023-05-31 02:11:38 Re: Pg 16: will pg_dump & pg_restore be faster?
Previous Message Bruce Momjian 2023-05-31 01:13:08 Re: Pg 16: will pg_dump & pg_restore be faster?