Tom Lane wrote:
> <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>
While agree in principle with your view on bzip2, I think there is a strong
reason why you should use it, 20%
That 20% is quite valuable. Just by switching to bzip2, the hosting companies
can deliver 20% more downloads with the same equipment and bandwidth cost. The
people with slow connections can get it 20% faster.
Will bzip2 become the standard? Probably not in general use, but for
downloadable tarballs it is rapidly becoming the standard. Those who pay for
bandwidth (server or client) welcome any improvement possible.
I would switch the argument around, time how long it takes to do:
ncftpget postgresql-xxxx.tar.gz
tar xpzvf postgresql-xxxx.tar.gz
cd postgresql-xxxx
./configure --option
make
make install
vs
ncftpget postgresql-xxxx.tar.bz2
bunzip2 -c postgresql-xxxx.tar.bz2 | tar xpzv
cd postgresql-xxxx
./configure --option
make
make install
The total time involved is almost identical, plus or minus a few seconds, but
on slow connections: users get postgresql faster and have to tie up a phone
line for a shorter amount of time.
The hosting company can serve 20% less bandwidth.
The archive takes up 20% less space on the mirrors.
The archine takes up 20% less space on server backups.
I don't think there is a compelling reason to keep a gzipped version.