| From: | "Neil Conway" <neilc(at)samurai(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, "Heikki Linnakangas" <hlinnaka(at)iki(dot)fi>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: fixing LISTEN/NOTIFY |
| Date: | 2005-10-09 17:55:39 |
| Message-ID: | 63069.69.199.116.160.1128880539.squirrel@69.199.116.160 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane said:
> But I think you might be confusing that with the feature-or-bug
> (depending on one's point of view) that duplicate notifications can be
> merged into one event. I'm inclined to preserve that behavior,
> primarily because not doing so would create a tremendous penalty on
> applications that expect it to work that way.
What sort of application are you envisioning?
If you mean there are applications for which avoiding duplicate
notifications is a performance win, I think those applications are on
shakey ground: the LISTEN/NOTIFY interface doesn't guarantee that no
duplicate notifications will be delivered (it merely doesn't guarantee
they *will* be delivered).
Personally, I think delivering all notifications by default is simpler
behavior for the application programmer to understand. If you want to
avoid doing work for duplicate notifications, you realistically need to
implement that yourself anyway.
-Neil
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2005-10-09 20:04:05 | Re: fixing LISTEN/NOTIFY |
| Previous Message | Tom Lane | 2005-10-09 16:24:29 | Re: avoid pulling up subquerys that contain volatile functions? |