| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Glaesemann <grzm(at)seespotcode(dot)net> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, David Fetter <david(at)fetter(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: minimal update |
| Date: | 2007-11-08 15:07:41 |
| Message-ID: | 24321.1194534461@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2007-11-08 15:19:58 | Re: A small rant about coding style for backend functions |
| Previous Message | Tom Lane | 2007-11-08 15:01:09 | Re: Estimation problem with a LIKE clause containing a / |