Re: Performance Improvement by reducing WAL for Update Operation

From: Haribabu kommi <haribabu(dot)kommi(at)huawei(dot)com>
To: "'Greg Smith'" <greg(at)2ndQuadrant(dot)com>
Cc: "'Mike Blackwell'" <mike(dot)blackwell(at)rrd(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Subject: Re: Performance Improvement by reducing WAL for Update Operation
Date: 2013-09-05 11:43:03
Message-ID: 8977CB36860C5843884E0A18D8747B036B9A4B04@szxeml558-mbs.china.huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 23 July 2013 17:35 Amit Kapila wrote:
>On Tuesday, July 23, 2013 12:02 AM Greg Smith wrote:
>> The v3 patch applies perfectly here now. Attached is a spreadsheet
>> with test results from two platforms, a Mac laptop and a Linux server.
>> I used systems with high disk speed because that seemed like a worst
>> case for this improvement. The actual improvement for shrinking WAL
>> should be even better on a system with slower disks.

>You are absolutely right.
>To mimic it on our system, by configuring RAMFS for database, it shows similar results.

>> Is possible to add a setting here that disables the feature altogether?

>Yes, it can be done in below 2 ways:
>1. Provide a new configuration parameter (wal_update_compression) to turn on/off this feature.
>2. At table level user can be given option to configure

>The main benefit of this patch is to reduce WAL for improving time in I/O, But I think for faster I/O systems, the calculation to reduce WAL has overhead.
>I will check how to optimize that calculation, but I think this feature should be consider with configuration knob as it can improve many cases.

I tried to improve the performance of this feature on faster I/O systems where the calculation to reduce the WAL is an overhead, but resulted no success.
But this optimization is beneficial for a systems where the I/O is a bottleneck. To support those use cases I have added a configuration parameter "wal_update_optimization"
which is off by default. User can enable/disable this optimization for update operations based on its need. During replay of WAL record it can be identified easily as
it is an encode wal tuple or not by checking the flags.

Please let me know your suggestions on the same.

Regards,
Hari babu.

Attachment Content-Type Size
pglz-with-micro-optimization-compress-using-newdata-4.patch application/octet-stream 39.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2013-09-05 11:57:39 Re: Is it necessary to rewrite table while increasing the scale of datatype numeric???
Previous Message Heikki Linnakangas 2013-09-05 10:29:23 Re: Analysis on backend-private memory usage (and a patch)