Re: Size of PostgreSQL backup ./. Sybase DUMP

From: Thomas Kellerer <shammat(at)gmx(dot)net>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Size of PostgreSQL backup ./. Sybase DUMP
Date: 2021-04-17 13:29:19
Message-ID: 409c895e-af72-00fb-9397-64066c7a7062@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Matthias Apitz schrieb am 17.04.2021 um 08:59:
> As I said, the Sybase DUMP command dumps a single database, i.e. works
> more like pg_dump of PostgreSQL. Ofc, they're like apples and oranges,
> but the netto data of the tables must be written to disk, and as I said
> above in both cases compressed with gzip.
>
> Even more, the pg_basebackup does not only write the netto data of the
> database, but also system tables and configuration information of the
> PG server. That made me asking, why it's less than the half in size as
> the gzip'ed DUMP of Sybase.
>
> One reason I could imagine is, that Sybase's DUMP writes all the pages,
> even the unused pages into the output file. But this is a guess, because
> I never investigated the internals of Sybase's DUMP command.

Actually pg_basebackup writes the data of **all** databases, not just one.

I wonder if the difference is because Sybase uses a single container file
for each database. And that container file might be bigger than the actual
content due to deleting data, or dropping tables. Postgres uses one file
per table (multiple files if the table size exceeds 1GB). So if you drop
a table in Postgres the space is immediately freed.

I know that in SQL Server there is a way to shrink the database files
(=containers). If that is possible in Sybase as well, you could try
and compare the size then.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Joel Jacobson 2021-04-18 18:58:53 Planning time grows exponentially with levels of nested views
Previous Message Matthias Apitz 2021-04-17 06:59:31 Re: Size of PostgreSQL backup ./. Sybase DUMP