On Sat, 05 Jul 2025 14:30:20 -0400 Tom Lane wrote:
Forgive my ignorance; always trying to learn more... :)
>p...@pfortin.com writes:
>> On Sat, 5 Jul 2025 11:11:32 -0700 Adrian Klaver wrote:
>>> How did you measure above?
>
>> # du -sb /var/lib/pgsql/data
>> 8227910662297 /var/lib/pgsql/data
>
>It's likely that there's a deal of bloat in that. Even if there's not
>much bloat, this number will include indexes and WAL data that don't
>appear in pg_dump output.
Does this imply that on restore, I'll have to re-index everything?
>>> What was the pg_dump command?
>
>> Didn't try given:
>> $ df /mnt/db
>> Filesystem Size Used Avail Use% Mounted on
>> /dev/sdh1 17T 13T 3.0T 82% /mnt/db
>
>I'd say give it a try; be sure to use one of the pg_dump modes
>that compress the data.
OK... I failed to mention I have several databases in this cluster; so
digging into pg_dumpall, I see:
--binary-upgrade
This option is for use by in-place upgrade utilities. Its use for
other purposes is not recommended or supported. The behavior of the
option may change in future releases without notice.
pg_upgrade has --link option; but I'm puzzled by this option in a
dumpall/restore process. My imagination wonders if this alludes to a way
to do something like:
pg_dumpall --globals-only --roles-only --schema-only ...
Would restoring this be a way to update only the control structures? Big
assumption that the actual data remains untouched...
Inquiring mind... :)
Back to my upgrade issue...
All my DBs are static (only queries once loaded). Assuming the dumpall
file fits on one of my drives:
pg_dumpall -f <path>/PG.backup -v
appears to be all I need? pg_dump has compression by default; but I don't
see compression with dumpall other than for TOAST.
Thanks, You guys are awesome!
> regards, tom lane
