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 |
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) |