Re: pg_dump additional options for performance

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: pg_dump additional options for performance
Дата
Msg-id 20080226141226.GQ528@svr2.hagander.net
обсуждение исходный текст
Ответ на Re: pg_dump additional options for performance  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: pg_dump additional options for performance  (Simon Riggs <simon@2ndquadrant.com>)
Re: pg_dump additional options for performance  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
Список pgsql-hackers
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.


> BTW, parallel dumping might be important, but is really much less so 
> than parallel restoring in my book.

By far. The only case where you want the backup to max out your system
would be during an "offline upgrade"... You don't want a regular backup to
max things out, because it will slow other things down. Whereas if you're
doing a restore, you most likely want your data back up ASAP.

//Magnus


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: pgAgent job limit
Следующее
От: "Roberts, Jon"
Дата:
Сообщение: Re: pgAgent job limit