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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Amit kapila <amit(dot)kapila(at)huawei(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <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 04:48:39
Message-ID: 15929.1348721319@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Karl O. Pinc 2012-09-27 05:43:19 Remove #include psqlscan.c from psql
Previous Message Amit Kapila 2012-09-27 04:30:12 Re: Switching timeline over streaming replication