Re: In-order pg_dump (or in-order COPY TO) - Mailing list pgsql-general

From Adrian Klaver
Subject Re: In-order pg_dump (or in-order COPY TO)
Date
Msg-id ccf26ec1-4fdf-496f-b222-de700071bdc1@aklaver.com
Whole thread Raw
In response to Re: In-order pg_dump (or in-order COPY TO)  (Dimitrios Apostolou <jimis@gmx.net>)
Responses Re: In-order pg_dump (or in-order COPY TO)
List pgsql-general
On 8/30/25 18:21, Dimitrios Apostolou wrote:
> Sorry I was not remembering the details. Probably there is a TOC in your dump file, but it does not contain any
positionsfor the data. The pg_restore command has to scan the whole file in advance, and fill in the TOC offsets in
memory.
> 
> This scanning happens in a very inefficient way, with many seek calls and small block reads. Try strace to see them.
Thisinitial phase can take hours in a huge dump file, before even starting any actual restoration.
 

It may be that my coffee is not strong enough, but I don't understand 
what you are trying to say.

Are you using, from previous post, the following?:

"Two patches for speeding up scanning an archive without TOC, like the 
one I'm having (because it is piped into borg, instead of written to 
file). These were activated, but shouldn't matter. They only build the 
TOC in pg_restore's memory. "

The part I don't see is how you get a dump file without a TOC?

When I do the pg_dump and pipe it to Borg the resulting file has a TOC.

Can you show the rest of the  |  borg create ...  command?

> 
> Thank you for testing.
> Dimitris
> 
> On 30 August 2025 20:19:13 CEST, Adrian Klaver <adrian.klaver@aklaver.com> wrote:



-- 
Adrian Klaver
adrian.klaver@aklaver.com



pgsql-general by date:

Previous
From: Dimitrios Apostolou
Date:
Subject: Re: In-order pg_dump (or in-order COPY TO)
Next
From: Dimitrios Apostolou
Date:
Subject: Re: In-order pg_dump (or in-order COPY TO)