Re: pg_dump additional options for performance

Tom Lane wrote:
> "Joshua D. Drake" <jd@commandprompt.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.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support