Tom Lane wrote: > "Joshua D. Drake" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
