Re: [HACKERS] [BUGS] Postgresql bug report - unexpected behavior ofsuppress_redundant_updates_trigger - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [HACKERS] [BUGS] Postgresql bug report - unexpected behavior ofsuppress_redundant_updates_trigger
Date
Msg-id 20170619171906.4lvo4dozwuufpfiy@alvherre.pgsql
Whole thread Raw
In response to Re: [HACKERS] [BUGS] Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Mon, Jun 19, 2017 at 11:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> I don't think it's a bug, I think it's an intentional design tradeoff.
> >> To suppress an update in this case, the trigger would have to grovel
> >> through the individual fields and detoast them before comparing.
> >> That would add a lot of cycles, and only seldom add successes.
> >> 
> >> Possibly we should adjust the documentation so that it doesn't imply
> >> that this trigger guarantees to suppress every no-op update.
> 
> > That doesn't sound like a very plausible argument to me.  I don't
> > think that a proposal to add a function named
> > sometimes_suppress_redundant_updates_trigger() would've attracted many
> > votes.
> 
> You'd be wrong.  The entire point of this trigger is to save cycles,
> so having it eat a lot of cycles only to fail is not an improvement.

I suppose that either behavior may be desirable depending on
circumstances.  Maybe it is possible to have each installed trigger be
configurable so that it can select either behavior.  (Maybe use the
trigger argument as a column list, and for each column in the list, do a
full detoast and compare instead of relying on toast pointer equality).

The current behavior seems more convenient in more cases, and so should
remain the default.

But this sounds like an additional feature, not a bug.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] Decimal64 and Decimal128
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] GSoC 2017 weekly progress reports (week 3)