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

From Greg Smith
Subject Re: pg_dump additional options for performance
Date
Msg-id Pine.GSO.4.64.0802261408480.20468@westnet.com
Whole thread Raw
In response to Re: pg_dump additional options for performance  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_dump additional options for performance
List pgsql-hackers
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.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: pg_dump additional options for performance
Next
From: Alvaro Herrera
Date:
Subject: Re: pg_dump additional options for performance