Re: Re: [WIP] Performance Improvement by reducing WAL for Update Operation

From: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'Noah Misch'" <noah(at)leadboat(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>, "'Heikki Linnakangas'" <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Subject: Re: Re: [WIP] Performance Improvement by reducing WAL for Update Operation
Date: 2012-09-27 05:50:56
Message-ID: 008b01cd9c74$10cad4c0$32607e40$@kapila@huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thursday, September 27, 2012 10:19 AM
> Noah Misch <noah(at)leadboat(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Farina 2012-09-27 08:21:16 Re: Oid registry
Previous Message Karl O. Pinc 2012-09-27 05:43:19 Remove #include psqlscan.c from psql