On Tue, Oct 15, 2013 at 6:30 AM, KONDO Mitsumasa <kondo.mitsum...@lab.ntt.co.jp> wrote: > (2013/10/13 0:14), Amit Kapila wrote: >> >> On Fri, Oct 11, 2013 at 10:36 PM, Andres Freund <and...@2ndquadrant.com> >> wrote: >>> >>> But maybe pglz is just not a good fit for this, it really >>> isn't a very good algorithm in this day and aage. > > +1. This compression algorithm is needed more faster than pglz which is like > general compression algorithm, to avoid the CPU bottle-neck. I think pglz > doesn't have good performance, and it is like fossil compression algorithm. > So we need to change latest compression algorithm for more better future. > > >> Do you think that if WAL reduction or performance with other >> compression algorithm (for ex. snappy) is better, then chances of >> getting the new compression algorithm in postresql will be more? > > Latest compression algorithms papers(also snappy) have indecated. I think it > is enough to select algorithm. It may be also good work in postgres.
Snappy is good mainly for un-compressible data, see the link below: http://www.postgresql.org/message-id/CAAZKuFZCOCHsswQM60ioDO_hk12tA7OG3YcJA8v=4yebmoa...@mail.gmail.com I think it is bit difficult to prove that any one algorithm is best for all kind of loads. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
