Re: Compression of full-page-writes - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Compression of full-page-writes
Date
Msg-id 20131011170655.GB4056218@alap2.anarazel.de
Whole thread Raw
In response to Re: Compression of full-page-writes  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Compression of full-page-writes  (Amit Kapila <amit.kapila16@gmail.com>)
Re: Compression of full-page-writes  (Jesper Krogh <jesper@krogh.cc>)
List pgsql-hackers
On 2013-10-11 09:22:50 +0530, Amit Kapila wrote:
> I think it will be difficult to prove by using any compression
> algorithm, that it compresses in most of the scenario's.
> In many cases it can so happen that the WAL will also not be reduced
> and tps can also come down if the data is non-compressible, because
> any compression algorithm will have to try to compress the data and it
> will burn some cpu for that, which inturn will reduce tps.

Then those concepts maybe aren't such a good idea after all. Storing
lots of compressible data in an uncompressed fashion isn't an all that
common usecase. I most certainly don't want postgres to optimize for
blank padded data, especially if it can hurt other scenarios. Just not
enough benefit.
That said, I actually have relatively high hopes for compressing full
page writes. There often enough is lot of repetitiveness between rows on
the same page that it should be useful outside of such strange
scenarios. But maybe pglz is just not a good fit for this, it really
isn't a very good algorithm in this day and aage.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Next
From: Magnus Hagander
Date:
Subject: Re: Auto-tuning work_mem and maintenance_work_mem