| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-patches(at)postgresql(dot)org |
| Subject: | Re: pg_dump additional options for performance |
| Date: | 2008-07-27 23:42:24 |
| Message-ID: | 488D07E0.4020303@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
Joshua D. Drake wrote:
>
> Agreed but that is a problem I understand with a solution I don't. I
> am all eyes on a way to fix that. One thought I had and please, be
> gentle in response was some sort of async transaction capability. I
> know that libpq has the ability to send async queries. Is it possible
> to do this:
>
> send async(copy table to foo)
> send async(copy table to bar)
> send async(copy table to baz)
>
> Where all three copies are happening in the background?
>
>
IIRC, libpq doesn't let you have more than one async query active at one
time.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua D. Drake | 2008-07-28 00:24:42 | Re: pg_dump additional options for performance |
| Previous Message | Stephen R. van den Berg | 2008-07-27 19:00:04 | Re: Protocol 3, Execute, maxrows to return, impact? |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua D. Drake | 2008-07-28 00:24:42 | Re: pg_dump additional options for performance |
| Previous Message | Joshua D. Drake | 2008-07-27 16:57:17 | Re: pg_dump additional options for performance |