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

On Thu, Sep 11, 2014 at 1:46 AM, Rahila Syed <rahilasyed.90@gmail.com> wrote:
>>I will repeat the above tests with high load on CPU and using the benchmark
> given by Fujii-san and post the results.
>
> Average % of CPU usage at user level for each of the compression algorithm
> are as follows.
>
> Compression        Multiple            Single
>
> Off                        81.1338            81.1267
> LZ4                      81.0998            81.1695
> Snappy:                80.9741             80.9703
> Pglz :                    81.2353            81.2753
>
> <http://postgresql.1045698.n5.nabble.com/file/n5818552/CPU_utilization_user_single.png>
> <http://postgresql.1045698.n5.nabble.com/file/n5818552/CPU_utilization_user.png>
>
> The numbers show CPU utilization of Snappy is the least. The CPU utilization
> in increasing order is
> pglz > No compression > LZ4 > Snappy
>
> The variance of average CPU utilization numbers is very low. However ,
> snappy seems to be best when it comes to lesser utilization of CPU.
>
> As per the measurement results posted till date
>
> LZ4 outperforms snappy and pglz in terms of compression ratio and
> performance. However , CPU utilization numbers show snappy utilizes least
> amount of CPU . Difference is not much though.
>
> As there has been no consensus yet about which compression algorithm to
> adopt, is it better to make this decision independent of the FPW compression
> patch as suggested earlier in this thread?. FPW compression can be done
> using built in compression pglz as it shows considerable performance over
> uncompressed WAL and good compression ratio
> Also, the patch to compress multiple blocks at once gives better compression
> as compared to single block. ISTM that performance overhead introduced by
> multiple blocks compression is slightly higher than single block compression
> which can be tested again after modifying the patch to use pglz .  Hence,
> this patch can be built using multiple blocks compression.

I advise supporting pglz only for the initial patch, and adding
support for the others later if it seems worthwhile.  The approach
seems to work well enough with pglz that it's worth doing even if we
never add the other algorithms.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company