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
