Re: pg_dump additional options for performance - Mailing list pgsql-hackers

From Christopher Browne
Subject Re: pg_dump additional options for performance
Date
Msg-id d6d6637f0802110956u505c0787jdf12a932b6f909aa@mail.gmail.com
Whole thread Raw
In response to Re: pg_dump additional options for performance  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: pg_dump additional options for performance  (Decibel! <decibel@decibel.org>)
List pgsql-hackers
On Feb 11, 2008 3:41 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Mon, 2008-02-11 at 10:29 -0500, Andrew Dunstan wrote:
> >
> > Alvaro Herrera wrote:
> > > --multidump-prefix=foobar
> > > and it creates foobar.1.predata, foobar.2.data, foobar.3.postdata
> > >
> > > or something like that?  The number would help to sort them
> > > appropriately, and the string would ensure that you know what each file
> > > is ... perhaps we could have %-escapes in the name to expand to both of
> > > these?  Perhaps we could have other %-escapes for things like database
> > > name --- so you could say --multidump-filename=%d.%n.%t.dump ... but
> > > then it would be nice to have strftime escapes too.
> > >
> > > Or is this too complex?
> > >
> >
> > Yes, I think it is. We do not have to be infinitely flexible. KISS seems
> > apposite.
>
> What syntax do you suggest?
>
> How about we use the --file as the prefix?
> and just use a postfix of .1 and .2 and .3

It seems better to me to have a suffix that suggests some sort of
meaning.  I'm not sure of the ideal names, but starting with:
.pre-schema, .data, and .post-schema as possibilities seems like a
route to get to possibly-better names...

-- 
http://linuxfinances.info/info/linuxdistributions.html
"The definition of insanity is doing the same thing over and over and
expecting different results."  -- assortedly attributed to Albert
Einstein, Benjamin Franklin, Rita Mae Brown, and Rudyard Kipling


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_dump additional options for performance
Next
From: Manolo _
Date:
Subject: Avoid scanning on tape