| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, 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 19:18:36 |
| Message-ID: | 20080226191836.GL5763@alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> "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.
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2008-02-26 19:33:54 | Two Coverity Scan volunteers needed |
| Previous Message | Greg Smith | 2008-02-26 19:17:24 | Re: pg_dump additional options for performance |