Re: minimal update
От | Gurjeet Singh |
---|---|
Тема | Re: minimal update |
Дата | |
Msg-id | 65937bea0803180631o78d44cd7n2928834bcdb101fd@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: minimal update (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: minimal update
(Andrew Dunstan <andrew@dunslane.net>)
|
Список | pgsql-hackers |
On Fri, Mar 7, 2008 at 9:40 PM, Bruce Momjian <bruce@momjian.us> wrote:
I am starting to implement this. Do we want to have this trigger function in the server, or in an external module?
Best regards,
--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ 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
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@seespotcode.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@momjian.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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ 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
В списке pgsql-hackers по дате отправления:
Следующее
От: Dan SearleДата:
Сообщение: Collating records based on a custom group by (aggregate like) function