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
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 |