Re: pg_dump additional options for performance

On Tue, 2008-02-26 at 16:18 -0300, Alvaro Herrera wrote:
> Tom Lane wrote:
> > "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> > > IMO the place to start is COPY which is per my tests, slow. Multi
> > > worker connection restore is great and I have proven that with some
> > > work it can provide o.k. results but it is certainly not acceptable.
> >
> > It was already pointed out to you that we can hope for only incremental
> > speedups in COPY per se. Don't be too quick to dismiss the discussion
> > of large-grain parallelism, because I don't see anything else within
> > reach that might give integer multiples rather than percentage points.
>
> Well, one idea would be dividing the input file in similarly-sized parts
> and giving each one to a different COPY process. This would help in
> cases where you have a single very large table to restore.
>
> Another thing we could do is selective binary output/input for bytea
> columns, to avoid the escaping step.

This is exactly what Dimitri is working on.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com