Re: The trap when using pg_dumpall
От | hubert depesz lubaczewski |
---|---|
Тема | Re: The trap when using pg_dumpall |
Дата | |
Msg-id | 20210704083527.GA20249@depesz.com обсуждение исходный текст |
Ответ на | Re: The trap when using pg_dumpall ("Dean Gibson (DB Administrator)" <postgresql@mailpen.com>) |
Список | pgsql-admin |
On Sat, Jul 03, 2021 at 11:04:26PM -0700, Dean Gibson (DB Administrator) wrote: > Well, I never store the output of pg_dumpall directly; I pipe it through > gzip, & the resultant size differs by about 1% from the size from pg_dump in > custom-archive format. > > I also found that pg_dumpall -g doesn't get the triggers; pg_dumpall -s > does. I don't know if pg-dump gets the triggers. Triggers are inside database, so normal pg_dump handles them. Generally, I stand firmly in position that one should never use pg_dumpall. Size of dump is one thing, but inability to sanely filter what you will load is deal breaker. Plus - with modern pg_dump and -Fd, both dumping time, and loading time can be significantly reduced thanks to parallelism. Wrote about it: https://www.depesz.com/2019/12/10/how-to-effectively-dump-postgresql-databases/ depesz
В списке pgsql-admin по дате отправления: