Re: pg_dump additional options for performance

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_dump additional options for performance
Date: 2008-02-26 18:58:25
Message-ID: 6124.1204052305@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2008-02-26 19:08:31 Re: pg_dump additional options for performance
Previous Message Tom Lane 2008-02-26 18:55:01 Re: Proposed changes to DTrace probe implementation