Re: pg_dump additional options for performance

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Greg Smith <gsmith(at)gregsmith(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_dump additional options for performance
Date: 2008-02-26 19:47:55
Message-ID: 20080226114755.16e447f2@commandprompt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 26 Feb 2008 14:17:24 -0500 (EST)
Greg Smith <gsmith(at)gregsmith(dot)com> wrote:

> On Tue, 26 Feb 2008, Tom Lane wrote:
>
> > What are you imagining here ... a plain SQL script containing
> > database-independent INSERT commands? That's going to suck compared
> > to COPY no matter what.
>
> Think 100GB+ of data that's in a CSV or delimited file. Right now
> the best import path is with COPY, but it won't execute very fast as
> a single process. Splitting the file manually will take a long time
> (time that could be spend loading instead) and substantially increase
> disk usage, so the ideal approach would figure out how to load in
> parallel across all available CPUs against that single file.

You mean load from position? That would be very, very cool.

Joshua D. Drake

- --
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL SPI Liaison | SPI Director | PostgreSQL political pundit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHxGzrATb/zqfZUUQRAujfAJ9xUIbj/DwN1QoyzR8a6O7B7FfK/wCffl3T
Ruu+TzTVMoDkj0a5pHMePX0=
=jlVQ
-----END PGP SIGNATURE-----

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2008-02-26 19:50:35 Re: pg_dump additional options for performance
Previous Message Robert Lor 2008-02-26 19:45:04 Re: Proposed changes to DTrace probe implementation