| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Stephen Denne" <Stephen(dot)Denne(at)datamail(dot)co(dot)nz> |
| Cc: | "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>, "Mark Mielke" <mark(at)mark(dot)mielke(dot)cc>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: count(*) performance improvement ideas |
| Date: | 2008-04-17 00:20:59 |
| Message-ID: | 5522.1208391659@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Stephen Denne" <Stephen(dot)Denne(at)datamail(dot)co(dot)nz> writes:
> Aside: It is currently more cumbersome to get a function to run, if needed, at commit. Ideal solution would be something like "EXECUTE ON COMMIT my_function()" or maybe "SAVEPOINT my_name ON COMMIT my_function()", but these suggestions are made without investigating what provision the SQL standard has made to address this need.
There is none, and the reason seems pretty obvious to me. What if your
"on commit" function fails? Or if you have two, and the second one
fails? Or even more to the point, the second one does something that
the first one expected to see the effects of?
Transaction commit is an exceedingly subtle and carefully structured
thing. Throwing random user-defined code into it ain't gonna happen.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PFC | 2008-04-17 00:30:44 | Re: count(*) performance improvement ideas |
| Previous Message | Bruce Momjian | 2008-04-17 00:19:43 | Re: Lessons from commit fest |