| From: | KONDO Mitsumasa <kondo(dot)mitsumasa(at)lab(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | "ktm(at)rice(dot)edu" <ktm(at)rice(dot)edu> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Compression of full-page-writes |
| Date: | 2013-10-16 04:42:34 |
| Message-ID: | 525E193A.7010206@lab.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
(2013/10/15 22:01), ktm(at)rice(dot)edu wrote:
> Google's lz4 is also a very nice algorithm with 33% better compression
> performance than snappy and 2X the decompression performance in some
> benchmarks also with a bsd license:
>
> https://code.google.com/p/lz4/
If we judge only performance, we will select lz4. However, we should think
another important factor which is software robustness, achievement, bug
fix history, and etc... If we see unknown bugs, can we fix it or improve
algorithm? It seems very difficult, because we only use it and don't
understand algorihtms. Therefore, I think that we had better to select
robust and having more user software.
Regards,
--
Mitsumasa KONDO
NTT Open Source Software
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavan Deolasee | 2013-10-16 05:33:12 | Re: Standby catch up state change |
| Previous Message | Peter Geoghegan | 2013-10-16 04:26:39 | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |