Re: [REVIEW] Re: Compression of full-page-writes

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Rahila Syed <rahilasyed90(at)gmail(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, Rahila Syed <rahilasyed(dot)90(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [REVIEW] Re: Compression of full-page-writes
Date: 2014-08-18 17:06:15
Message-ID: CA+TgmoZ6U+M9ZwpTNawFiN=+jRbPfv3m_ZqLc7YH3viM78RoVg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 18, 2014 at 7:19 AM, Rahila Syed <rahilasyed90(at)gmail(dot)com> wrote:
>>According to the measurement result, the amount of WAL generated in
>>"Multiple Blocks in one run" than that in "Single Block in one run".
>>So ISTM that compression of multiple blocks at one run can improve
>>the compression ratio. Am I missing something?
>
> Sorry for using unclear terminology. WAL generated here means WAL that gets
> generated in each run without compression.
> So, the value WAL generated in the above measurement is uncompressed WAL
> generated to be specific.
> uncompressed WAL = compressed WAL + Bytes saved.
>
> Here, the measurements are done for a constant amount of time rather than
> fixed number of transactions. Hence amount of WAL generated does not
> correspond to compression ratios of each algo. Hence have calculated bytes
> saved in order to get accurate idea of the amount of compression in each
> scenario and for various algorithms.
>
> Compression ratio i.e Uncompressed WAL/compressed WAL in each of the above
> scenarios are as follows:
>
> Compression algo Multiple Blocks in one run Single Block in one run
>
> LZ4 1.21 1.27
>
> Snappy 1.19 1.25
>
> pglz 1.14 1.16
>
> This shows compression ratios of both the scenarios Multiple blocks and
> single block are nearly same for this benchmark.

I don't agree with that conclusion. The difference between 1.21 and
1.27, or between 1.19 and 1.25, is quite significant. Even the
difference beyond 1.14 and 1.16 is not trivial. We should try to get
the larger benefit, if it is possible to do so without an unreasonable
effort.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-08-18 17:08:56 Re: [REVIEW] Re: Compression of full-page-writes
Previous Message Robert Haas 2014-08-18 17:03:02 Re: Reporting the commit LSN at commit time