From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Dunstan <pgsql(at)tomd(dot)cc>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: pg_dump additional options for performance |
Date: | 2008-02-26 14:27:07 |
Message-ID: | 1204036027.4252.289.camel@ebony.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2008-02-26 at 15:12 +0100, Magnus Hagander wrote:
> On Tue, Feb 26, 2008 at 08:28:11AM -0500, Andrew Dunstan wrote:
> >
> >
> > Simon Riggs wrote:
> > >Separate files seems much simpler...
> > >
> > >
> >
> > Yes, We need to stick to the KISS principle.
> >
> > ISTM that we could simply invent a new archive format of "d" for directory.
>
> Yeah, you can always ZIP (or whatever) the resulting directory when you're
> done..
>
> But looking at it from a "backup tool perspective", like if you want to
> integrate it in your network backup solution, that might make it harder.
> Being able to deliver over a single, or over multiple, pipes is what's
> needed there. If you need to dump it to disk first and can only "pick it
> up" later, that'll require a lot more I/O and disk space.
>
> But I'm not sure that's a concern we need to think about in this case,
> just wanted to mention it.
If I'm using a network backup solution I'd be using physical backup,
which can already be parallelised.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Ron Mayer | 2008-02-26 14:27:46 | Re: pg_dump additional options for performance |
Previous Message | Peter Eisentraut | 2008-02-26 14:26:16 | pgsql: Don't build the win32 support files in the all target, only in |