Re: Determining size of a database before dumping

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Alexander Staubo <alex(at)purefiction(dot)net>, Madison Kelly <linux(at)alteeve(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Determining size of a database before dumping
Date: 2006-10-03 00:05:17
Message-ID: 16895.1159833917@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> On Tue, 2006-10-03 at 00:42 +0200, Alexander Staubo wrote:
>> Why does pg_dump serialize data less efficiently than PostgreSQL when
>> using the "custom" format?

> What you're saying is more theoretical. If pg_dump used specialized
> compression based on the data type of the columns, and everything was
> optimal, you're correct. There's no situation in which the dump *must*
> be bigger. However, since there is no practical demand for such
> compression, and it would be a lot of work ...

There are several reasons for not being overly tense about the pg_dump
format:

* We don't have infinite manpower

* Cross-version and cross-platform portability of the dump files is
critical

* The more complicated it is, the more chance for bugs, which you'd
possibly not notice until you *really needed* that dump.

In practice, pushing the data through gzip gets most of the potential
win, for a very small fraction of the effort it would take to have a
smart custom compression mechanism.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Morgan Kita 2006-10-03 00:21:40 Foreign keys, arrays, and uniqueness
Previous Message Jeff Davis 2006-10-02 23:12:29 Re: Determining size of a database before dumping