| From: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com> |
|---|---|
| To: | Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
| Subject: | Request For Feature: pg_dump |
| Date: | 2026-05-22 13:32:44 |
| Message-ID: | CANzqJaCNaqhQ9duPP+eKU2OR1wjGYW-FBQ2FZXqnBRb6XAnKQA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
In --format=directory mode, remove .dat files with zero data records, and
mark that table's toc.dat entry that it's an empty table.
Justification: *lots* of empty tables means *lots* of teeny-tiny files in
the DB's dump directory. That unnecessarily bloats the fs, and makes "du
-c" really really slow.
But why are there sooo many empty tables? You shouldn't have so many empty
tables!
Yeah, well, software (especially 3rd-party software that must be generic to
satisfy the varying needs of a large and varied customer base) can't always
be perfectly tuned to the precise and immediate needs of a particular
site. Partitioning makes that much much worse.
We've survived this long without it, but pgbackrest has a similar feature
(though implemented differently from how pg_dump would do it), and it's
*really* handy.
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Raj | 2026-05-22 14:23:51 | Re: Partitioning table - Update on partitioning key |
| Previous Message | Ron Johnson | 2026-05-21 17:50:21 | Re: Partitioning table - Update on partitioning key |