On Wed, Aug 27, 2014 at 11:52 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Tue, Aug 26, 2014 at 8:14 AM, Fujii Masao <masao.fu...@gmail.com> wrote:
>> On Tue, Aug 19, 2014 at 6:37 PM, Rahila Syed <rahilasye...@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 better in "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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
