Re: pg_dump additional options for performance

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_dump additional options for performance
Date: 2008-02-26 19:17:24
Message-ID: Pine.GSO.4.64.0802261408480.20468@westnet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2008-02-26 19:18:36 Re: pg_dump additional options for performance
Previous Message Josh Berkus 2008-02-26 19:11:32 Re: Including PL/PgSQL by default