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
