Thread: PostgreSQL downloads compressed with bzip2 instead of gzip ?
Hi, I know that for many people, file size is not much of an issue, but for many others I suspect it is. Whether that is for reasons of storage space on smaller drives, like on current laptops, or older machines. Plus, it can cut down on bandwidth usage. And if that's not enough reason, then how about simply because there is a better, more efficient way to compress than Gzip ? Therefore, I think it would be nice to have PostgreSQL downloads available compressed with bzip2 instead of gzip. Starting with version 7.3.3 perhaps ? Cheers, Joel
<snip>
> I know that for many people, file size is not much of an issue,
> but for many others I suspect it is. Whether that is for reasons
> of storage space on smaller drives, like on current laptops, or
> older machines.
Point of Information:
Improved compression efficiency does not help people with small drives.
Case in point: imagine sometime in the future a "supertarball" algorithm
is discovered. This wondrous new algorithm compresses terabytes of data
into a single bit. (Don't ask how -- the deranged computer scientist
who discovered it, went crazy doing so. You might be next!)
So Joe User boots up his trusty 386 with a 500MB hard drive, and dials
into AOL with a 9600 baud modem. He grabs postgresql-7.3.3.SUPERTARBALL
off the 'net, and types into his console (since he doesn't have enough
processing power to run a modern version of windows):
$ supertarball -xvf postgresql-7.3.3.SUPERTARBALL
And Joe User runs out of disk space.
Moral of the Story:
A smaller file to download (via better compression) only decreases the
time it takes to download.
:-D
--
Daniel R. Anderson
Great Lakes Industries, Inc.
80 Pineview Ave.
Buffalo, NY 14218
(716) 691-5900 x218
"Never let your schooling interfere with your education"
-- Mark Twain
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Moral of the Story: > > A smaller file to download (via better compression) only decreases the > time it takes to download. I think the real argument in favor of providing a bz2 alternative to gz *is* the time to download. Loading a Postgres tarball over a dialup line is much faster with bz2 rather than gz. This has been covered on the list before: I recall that most everyone agreed it was a good idea, but nobody on the website appeared ready to follow through with it and actually set up the bz2 files. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200303201036 -----BEGIN PGP SIGNATURE----- Comment: http://www.turnstep.com/pgp.html iD8DBQE+eeCfvJuQZxSWSsgRAvy+AJ9wWoOgXezn3p01/D4jed2sNqT6DQCfXkz5 0uvv7khQJ4LAXMYydMnpWdM= =Lg8Y -----END PGP SIGNATURE-----
How about both, until the tools become more readily availabe or bzip is built into Winzip. With windows versoin 'around the corner' it will be imiportant for the ease of installation for the usual windows joe to not have to hunt around the web for a command line only version of bzip and not use a gui (current situation for bzip). Joel Rodrigues wrote: > Hi, > > I know that for many people, file size is not much of an issue, but for > many others I suspect it is. Whether that is for reasons of storage > space on smaller drives, like on current laptops, or older machines. > Plus, it can cut down on bandwidth usage. And if that's not enough > reason, then how about simply because there is a better, more efficient > way to compress than Gzip ? > > Therefore, I think it would be nice to have PostgreSQL downloads > available compressed with bzip2 instead of gzip. Starting with version > 7.3.3 perhaps ? > > Cheers, > Joel > > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html >
I agree that bz2 might very well speed up download over a dialup line.
I was, however, pointing out that one of the arguments as to why
downloads should be available in bz2 format -- to minimize required disk
space -- was specious.
<snip>
> I think the real argument in favor of providing a bz2 alternative to gz
> *is* the time to download. Loading a Postgres tarball over a dialup line
> is much faster with bz2 rather than gz.
<snip>
--
Daniel R. Anderson
Great Lakes Industries, Inc.
80 Pineview Ave.
Buffalo, NY 14218
(716) 691-5900 x218
"Never let your schooling interfere with your education"
-- Mark Twain
I keep all downloads as bzip2 compressed archives on my drive in case (!:-) I ever need to re-install/re-compile. So, you see it *does* minimize required disk space. To suggest that an untarred, decompressed bzip2 archive would need less space than if it had been compressed using any other algorithm, would be an odd suggestion indeed. - Joel On Thursday, March 20, 2003, at 10:17 , Daniel R. Anderson wrote: > I agree that bz2 might very well speed up download over a dialup line. > I was, however, pointing out that one of the arguments as to why > downloads should be available in bz2 format -- to minimize > required disk > space -- was specious. > > <snip> >> I think the real argument in favor of providing a bz2 >> alternative to gz >> *is* the time to download. Loading a Postgres tarball over a >> dialup line >> is much faster with bz2 rather than gz. > <snip> > --
<snip>
> I keep all downloads as bzip2 compressed archives on my drive in
> case (!:-) I ever need to re-install/re-compile. So, you see it
> *does* minimize required disk space.
>
> To suggest that an untarred, decompressed bzip2 archive would
> need less space than if it had been compressed using any other
> algorithm, would be an odd suggestion indeed.
</snip>
I wasn't suggesting that an untarred, decompressed bzip2 archive would
need less space then a compressed one; I was simply pointing out that if
you're downloading it to install you need so much disk space. AND, if I
remember correctly bunzip2 -- like when you gunzip a *.gz -- removes the
extension.[0] So you'd have to recompress the tar file /anyways/ --
thus making it a negligible savings.
As far as saving files on your hard disk goes I'm not sure what benefit
you're getting. It's been my experience that saved sources go out of
date long before they're needed[1]. You're much better off setting up
CVS.[2]
[0] I'm not overly familiar with bzip2. I would assume you could use
some extension when you call bzip2 to keep a copy of the file in bzip2
format. But, then again you'd still need to rm -Rf the directory
created.
[1] Since you may need the sources to uninstall a program, in that
context I could understand keeping said code. But, again, in my
experience download time of old versions is negligible and most sites
have old code available. Then again, I am using a broadband
connection. :-D
[2] Yes, I realize that you save the sources for when you feel the need
to reinstall Debian/slackware/whatever distro you happen to have. But
if you're reinstalling every week you should stop doing everything while
root. ;-P
--
Daniel R. Anderson
Chief Lab Rat and Helper Monkey
Great Lakes Industries, Inc.
80 Pineview Ave.
Buffalo, NY 14218
(716) 691-5900 x218
"Never let your schooling interfere with your education"
-- Mark Twain
I keep all downloads as bzip2 compressed archives on my drive in case (!:-) I ever need to re-install/re-compile. So, you see it *does* minimize required disk space. To suggest that an untarred, decompressed bzip2 archive would need less space than if it had been compressed using any other algorithm, would be an odd suggestion indeed. - Joel On Thursday, March 20, 2003, at 10:17 , Daniel R. Anderson wrote: > I agree that bz2 might very well speed up download over a dialup line. > I was, however, pointing out that one of the arguments as to why > downloads should be available in bz2 format -- to minimize > required disk > space -- was specious. > > <snip> >> I think the real argument in favor of providing a bz2 >> alternative to gz >> *is* the time to download. Loading a Postgres tarball over a >> dialup line >> is much faster with bz2 rather than gz. > <snip> > --
On Monday, March 24, 2003, at 03:12 , Daniel R. Anderson wrote: > AND, if I > remember correctly bunzip2 -- like when you gunzip a *.gz -- > removes the > extension.[0] So you'd have to recompress the tar file /anyways/ -- > thus making it a negligible savings. Not necessarily so. Here are the aliases I've set up (I use Mac OS X) to make things easier : This will tar & compress a directory/file : alias bztar "gnutar --use=bzip2 -cvf" These will untar & decompress gzip or bzip2 files and leave no detritus : alias bzuntar "gnutar --use=bzip2 -xvf" alias gzuntar "tar -zxvf" Whether one uses broadband or whatever, it's nice to be able to conserve bandwidth, whether that is to save yourself money or simply reduce the load on servers. That would help other users and reduce the costs for all those nice open source people. Cheers, Joel
FWIW, the current version of tar uses
-z for gzip compression
-j for bzip2 compression
There is no need to specifically un{b}zip tars as the effective processes
are
tar -xjf xyz --becomes--> bunzip2 < xyz | tar -xf -
tar -xjf xyz ... --becomes--> tar -cf - ... | bzip2 > xyz
The primary advantage to providing the archive in bzip2 (instead of gzip)
format is the reduction of download time; saving storage space is a much
less significant issue.
Whether or not you save space with the archive is a separate issue, IMO
fairly insignificant given the difficulty in finding a new drive UNDER
40GB.
(Said by someone who just installed a 7.3.2 demo on a 16MB P-90 laptop
running RH70)
On 23 Mar 2003, Daniel R. Anderson wrote:
> <snip>
>
> I wasn't suggesting that an untarred, decompressed bzip2 archive would
> need less space then a compressed one; I was simply pointing out that if
> you're downloading it to install you need so much disk space. AND, if I
> remember correctly bunzip2 -- like when you gunzip a *.gz -- removes the
> extension.[0] So you'd have to recompress the tar file /anyways/ --
> thus making it a negligible savings.