From: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
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-28 00:24:42 |
Message-ID: | 488D11CA.9070803@commandprompt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Andrew Dunstan wrote:
>
>
> 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.
Now that I think on it harder, this isn't even a libpq problem (although
its involved), we need the postmaster do be able to do a background
async query. Which is (I am guessing) why libpq can only do one at a time.
Sincerely,
Joshua D. Drake
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2008-07-28 00:44:26 | Re: pg_dump additional options for performance |
Previous Message | Andrew Dunstan | 2008-07-27 23:42:24 | Re: pg_dump additional options for performance |
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2008-07-28 00:44:26 | Re: pg_dump additional options for performance |
Previous Message | Andrew Dunstan | 2008-07-27 23:42:24 | Re: pg_dump additional options for performance |