From: | hubert depesz lubaczewski <depesz(at)depesz(dot)com> |
---|---|
To: | "Dean Gibson (DB Administrator)" <postgresql(at)mailpen(dot)com> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: The trap when using pg_dumpall |
Date: | 2021-07-04 08:35:27 |
Message-ID: | 20210704083527.GA20249@depesz.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | pgdba pgdba | 2021-07-04 19:36:44 | Archive cleanup |
Previous Message | Dean Gibson (DB Administrator) | 2021-07-04 06:04:26 | Re: The trap when using pg_dumpall |