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

From Amit Kapila
Subject Re: Re: [WIP] Performance Improvement by reducing WAL for Update Operation
Date
Msg-id 008b01cd9c74$10cad4c0$32607e40$@kapila@huawei.com
Whole thread Raw
In response to Re: Re: [WIP] Performance Improvement by reducing WAL for Update Operation  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
  On Thursday, September 27, 2012 10:19 AM
> Noah Misch <noah@leadboat.com> writes:
> > You cannot assume executor-unmodified columns are also unmodified
> from
> > heap_update()'s perspective.  Expansion in one column may instigate
> TOAST
> > compression of a logically-unmodified column, and that counts as a
> change for
> > xlog delta purposes.
> 
> Um ... what about BEFORE triggers?
This optimization will not apply in case Before triggers updates the tuple.
> 
> Frankly, I think that expecting the executor to tell you which columns
> have been modified is a non-starter.  We have a solution for HOT and
> it's silly to do the same thing differently just a few lines away.
> 
My apprehension is that it can hit the performance advantage if we compare
all attributes to check which have been modified and that to under Buffer
Exclusive Lock.
In case of HOT only the index attributes get compared.

I agree that doing things differently at 2 nearby places is not good. 
So I will do it same way as for HOT and then take the performance data again
and if there is no big impact then
we can do it that way. 


With Regards,
Amit Kapila.




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: [WIP] Performance Improvement by reducing WAL for Update Operation
Next
From: Daniel Farina
Date:
Subject: Re: Oid registry