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

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Pg 16: will pg_dump & pg_restore be faster?
Дата
Msg-id CAApHDvrQ1bpzyS8k=nHsL0rNFNOkiGmiJRQGO4jUb4yPS4EysQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Pg 16: will pg_dump & pg_restore be faster?  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Pg 16: will pg_dump & pg_restore be faster?
Re: Pg 16: will pg_dump & pg_restore be faster?
Список pgsql-general
On Wed, 31 May 2023 at 13:13, Bruce Momjian <bruce@momjian.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



В списке pgsql-general по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Pg 16: will pg_dump & pg_restore be faster?
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Pg 16: will pg_dump & pg_restore be faster?