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

From Fujii Masao
Subject Re: [REVIEW] Re: Compression of full-page-writes
Date
Msg-id CAHGQGwH1y_+H4Fm3Vg9u8MVnDCBkQeZAHJ7wyGyCWcVPRBYxyQ@mail.gmail.com
Whole thread Raw
In response to Re: [REVIEW] Re: Compression of full-page-writes  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [REVIEW] Re: Compression of full-page-writes  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On Wed, Aug 27, 2014 at 11:52 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Aug 26, 2014 at 8:14 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> On Tue, Aug 19, 2014 at 6:37 PM, Rahila Syed <rahilasyed90@gmail.com> wrote:
>>> Hello,
>>> Thank you for comments.
>>>
>>>>Could you tell me where the patch for "single block in one run" is?
>>> Please find attached patch for single block compression in one run.
>>
>> Thanks! I ran the benchmark using pgbench and compared the results.
>> I'd like to share the results.
>>
>> [RESULT]
>> Amount of WAL generated during the benchmark. Unit is MB.
>>
>>                 Multiple                Single
>>     off            202.0                201.5
>>     on            6051.0                6053.0
>>     pglz            3543.0                3567.0
>>     lz4            3344.0                3485.0
>>     snappy            3354.0                3449.5
>>
>> Latency average during the benchmark. Unit is ms.
>>
>>                 Multiple                Single
>>     off            19.1                19.0
>>     on            55.3                57.3
>>     pglz            45.0                45.9
>>     lz4            44.2                44.7
>>     snappy            43.4                43.3
>>
>> These results show that FPW compression is really helpful for decreasing
>> the WAL volume and improving the performance.
>
> Yeah, those look like good numbers.  What happens if you run it at
> full speed, without -R?

OK, I ran the same benchmark except -R option. Here are the results:

[RESULT]
Throughput in the benchmark.
                           Multiple                    Single       off                    2162.6
2164.5      on                    891.8                    895.6       pglz                    1037.2
1042.3       lz4                    1084.7                    1091.8       snappy                    1058.4
      1073.3
 

Latency average during the benchmark. Unit is ms.
                           Multiple                    Single       off                    29.6                    29.6
     on                    71.7                    71.5       pglz                    61.7                    61.4
lz4                    59.0                    58.6       snappy                    60.5                    59.6
 

Amount of WAL generated during the benchmark. Unit is MB.
                           Multiple                    Single       off                    948.0
948.0      on                    7675.5                    7702.0       pglz                    5492.0
 5528.5       lz4                    5494.5                    5596.0       snappy                    5667.0
       5804.0
 

pglz vs. lz4 vs. snappy       In this benchmark, lz4 seems to have been the best compression
algorithm.       It caused best performance and highest WAL compression ratio.

Multiple vs. Single       WAL volume with "Multiple" was smaller than that with "Single". But       the throughput was
betterin "Single". So the "Multiple" is more useful       for WAL compression, but it may cause higher performance
overhead      at least in current implementation.
 

Regards,

-- 
Fujii Masao



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Next
From: Fujii Masao
Date:
Subject: Re: [REVIEW] Re: Compression of full-page-writes