Re: minimal update

From: "Gurjeet Singh" <singh(dot)gurjeet(at)gmail(dot)com>
To: "Bruce Momjian" <bruce(at)momjian(dot)us>
Cc: "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Michael Glaesemann" <grzm(at)seespotcode(dot)net>, "David Fetter" <david(at)fetter(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: minimal update
Date: 2008-03-18 13:31:26
Message-ID: 65937bea0803180631o78d44cd7n2928834bcdb101fd@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 7, 2008 at 9:40 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

>
> I assume don't want a TODO for this? (Suppress UPDATE no changed
> columns)
>

I am starting to implement this. Do we want to have this trigger function in
the server, or in an external module?

Best regards,

>
>
> ---------------------------------------------------------------------------
>
> Andrew Dunstan wrote:
> >
> >
> > Tom Lane wrote:
> > > Michael Glaesemann <grzm(at)seespotcode(dot)net> writes:
> > >
> > >> What would be the disadvantages of always doing this, i.e., just
> > >> making this part of the normal update path in the backend?
> > >>
> > >
> > > (1) cycles wasted to no purpose in the vast majority of cases.
> > >
> > > (2) visibly inconsistent behavior for apps that pay attention
> > > to ctid/xmin/etc.
> > >
> > > (3) visibly inconsistent behavior for apps that have AFTER triggers.
> > >
> > > There's enough other overhead in issuing an update (network,
> > > parsing/planning/etc) that a sanely coded application should try
> > > to avoid issuing no-op updates anyway. The proposed trigger is
> > > just a band-aid IMHO.
> > >
> > > I think having it as an optional trigger is a reasonable compromise.
> > >
> > >
> > >
> >
> > Right. I never proposed making this the default behaviour, for all these
> > good reasons.
> >
> > The point about making the app try to avoid no-op updates is that this
> > can impose some quite considerable code complexity on the app,
> > especially where the number of updated fields is large. It's fragile and
> > error-prone. A simple switch that can turn a trigger on or off will be
> > nicer. Syntax support for that might be even nicer, but there appears to
> > be some resistance to that, so I can easily settle for the trigger.
> >
> > cheers
> >
> > andrew
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Have you searched our list archives?
> >
> > http://archives.postgresql.org
>
> --
> Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
> EnterpriseDB http://postgres.enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

--
gurjeet[(dot)singh](at)EnterpriseDB(dot)com
singh(dot)gurjeet(at){ gmail | hotmail | indiatimes | yahoo }.com

EnterpriseDB http://www.enterprisedb.com

17° 29' 34.37"N, 78° 30' 59.76"E - Hyderabad *
18° 32' 57.25"N, 73° 56' 25.42"E - Pune
37° 47' 19.72"N, 122° 24' 1.69" W - San Francisco

http://gurjeet.frihost.net

Mail sent from my BlackLaptop device

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2008-03-18 13:43:40 Re: CVS problems
Previous Message Alvaro Herrera 2008-03-18 13:21:44 Re: [COMMITTERS] pgsql: Enable probes to work with Mac OS X Leopard and other OSes that