Re: Performance Improvement by reducing WAL for Update Operation - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Performance Improvement by reducing WAL for Update Operation
Date
Msg-id 003c01ce7c5a$18afd340$4a0f79c0$@kapila@huawei.com
Whole thread Raw
In response to Re: Performance Improvement by reducing WAL for Update Operation  (Mike Blackwell <mike.blackwell@rrd.com>)
Responses Re: Performance Improvement by reducing WAL for Update Operation
List pgsql-hackers
On Tuesday, July 09, 2013 2:52 AM Mike Blackwell wrote:

> I can't comment on further direction for the patch, but since it was marked as Needs Review in the CF app I took a
quicklook at it. Thanks for looking into it. 
 Last time Heikki has found test scenario's where the original patch was not performing good.  He has also proposed a
differentapproach for WAL encoding and sent the modified patch which has comparatively less negative performance impact
and asked to check if the patch can reduce the performance impact for the scenario's mentioned by him. After that I
foundthat with some modification's (use new tuple data for  encoding) in his approach, it eliminates the negative
performanceimpact and  have WAL reduction for more number of cases. 
 I think the first thing to verify is whether the results posted can be validated in some other environment setup by
anotherperson.  The testcase used is posted at below link:
http://www.postgresql.org/message-id/51366323.8070606@vmware.com


> It patches and compiles clean against the current Git HEAD, and 'make check' runs successfully.

> Does it need documentation for the GUC variable 'wal_update_compression_ratio'?
 This variable has been added to test the patch for different compression_ratio during development test. It was not
decidedto have this variable permanently as part of this patch, so currently there is no documentation for it.  However
ifthe decision comes out to be that it needs to be part of patch, then documentation for same can be updated. 

With Regards,
Amit Kapila.




pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Should we automatically run duplicate_oids?
Next
From: Craig Ringer
Date:
Subject: Re: Should we automatically run duplicate_oids?