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
calculationto reduce WAL has overhead.
>I will check how to optimize that calculation, but I think this feature should be consider with configuration knob as
itcan 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
addeda configuration parameter "wal_update_optimization"
which is off by default. User can enable/disable this optimization for update operations based on its need. During
replayof 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.
