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

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: [REVIEW] Re: Compression of full-page-writes
Дата
Msg-id CAHGQGwH1y_+H4Fm3Vg9u8MVnDCBkQeZAHJ7wyGyCWcVPRBYxyQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [REVIEW] Re: Compression of full-page-writes  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [REVIEW] Re: Compression of full-page-writes  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список 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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: [REVIEW] Re: Compression of full-page-writes