Re: [HACKERS] Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger

Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Mon, Jun 19, 2017 at 11:59 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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