Re: pg_dump additional options for performance - Mailing list pgsql-hackers

From Zeugswetter Andreas ADI SD
Subject Re: pg_dump additional options for performance
Date
Msg-id E1539E0ED7043848906A8FF995BDA57902D064A0@m0143.s-mxs.net
Whole thread Raw
In response to Re: pg_dump additional options for performance  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
> > As a user I'd really prefer all of this to be much more transparent,
and could
> > well imagine the -Fc format to be some kind of TOC + zip of table
data + post
> > load instructions (organized per table), or something like this.
> > In fact just what you described, all embedded in a single file.
>
> If its in a single file then it won't perform as well as if its
separate
> files. We can put separate files on separate drives. We can begin
> reloading one table while another is still unloading. The OS will
> perform readahead for us on single files whereas on one file it will
> look like random I/O. etc.

Well, nowadays this is not generally true. You would most likely be
using stripesets, so you don't need more that one file for reading to be
using more than one spindle in parallel.
Also different threads or processes would be used, so readahead would be
done in parallel at different offsets in the file.

Andreas


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: pg_dump additional options for performance
Next
From:
Date:
Subject: Re: [PATCHES] 2WRS [WIP]