Skip site navigation (1) Skip section navigation (2)

Re: pg_dump additional options for performance

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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

In response to

Responses

pgsql-hackers by date

Next:From: Joshua D. DrakeDate: 2008-07-28 00:24:42
Subject: Re: pg_dump additional options for performance
Previous:From: Stephen R. van den BergDate: 2008-07-27 19:00:04
Subject: Re: Protocol 3, Execute, maxrows to return, impact?

pgsql-patches by date

Next:From: Joshua D. DrakeDate: 2008-07-28 00:24:42
Subject: Re: pg_dump additional options for performance
Previous:From: Joshua D. DrakeDate: 2008-07-27 16:57:17
Subject: Re: pg_dump additional options for performance

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group