Re: beta3

=?iso-8859-1?q?Mart=EDn=20Marqu=E9s?= <martin(at)bugs(dot)unl(dot)edu(dot)ar> writes:
> P.D.: bzip2 is slow, but you can get a real small package with it, even
> though PostgreSQL isn't that big, if we compare it with KDE or Mozilla.

As an experiment, I zipped my current PG source tree with both. (This
isn't an exact test of the distribution size, because I didn't bother
to get rid of the CVS control files, but it's pretty close.)

Original tar file: 37089280 bytes
gzip -9: 8183182 bytes
bzip2: 6762638 bytes

or slightly less than a 20% savings for bzip over gzip. That's useful,
but not exactly compelling. A comparison of unzip runtime also seems
relevant:

$ time gunzip pgsql.tar.gz

real 0m5.48s
user 0m4.46s
sys 0m0.62s

$ time bunzip2 pgsql.tar.bz2

real 0m27.77s
user 0m26.50s
sys 0m0.92s

If I'd downloaded this thing over a decent DSL or cable modem line,
bzip2 would actually be a net loss in total download + uncompress time.

<editorial>
The reason bzip is still an also-ran is that it's not enough better
than gzip to have persuaded people to switch over. My bet is that
bzip will always be an also-ran, and that gzip will remain the de
facto standard until something comes along that's really significantly
better, like a factor of 2 better. I've watched this sort of game
play out before, and I know you don't take over the world with a 20%
improvement over the existing standard. At least not without other
compelling reasons, like speed (oops) or patent freedom (no win there
either).
</editorial>

regards, tom lane