Re: pg_dump additional options for performance

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

In response to

Browse pgsql-hackers by date

  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

Browse pgsql-patches by date

  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