On Tue, 2008-02-26 at 16:18 -0300, Alvaro Herrera wrote: > 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.
This is exactly what Dimitri is working on. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
