Re: beta3
От | Tom Lane |
---|---|
Тема | Re: beta3 |
Дата | |
Msg-id | 29484.1006269417@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: beta3 (Martín Marqués <martin@bugs.unl.edu.ar>) |
Ответы |
Re: beta3
Re: beta3 |
Список | pgsql-hackers |
Martín Marqués <martin@bugs.unl.edu.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
В списке pgsql-hackers по дате отправления: