From: | Mikhail Terekhov <terekhov(at)emc(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Neil Conway <nconway(at)klamath(dot)dyndns(dot)org> |
Subject: | Re: notification: pg_notify ? |
Date: | 2002-04-03 15:03:01 |
Message-ID: | 3CAB19A5.3040103@emc.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> There is a very significant performance problem with LISTEN/NOTIFY
> via pg_listener: in any application that generates notifications at
> a significant rate, pg_listener will accumulate dead tuples at that
> same rate, and we will soon find ourselves wasting lots of time
> scanning through dead tuples. Frequent VACUUMs might help, but the
That's unfortunate, may be if backend could reuse tuple on updates could help?
> whole thing is really quite silly: why are we using a storage mechanism
> that's designed entirely for *stable* storage of data to pass inherently
> *transient* signals? If the system crashes, we have absolutely zero
Because there is no other easy way to guarantee message delivery?
> interest in the former contents of pg_listener (and indeed need to go
> to some trouble to get rid of them).
There is no free beer :)
Regards,
Mikhail Terekhov
From | Date | Subject | |
---|---|---|---|
Next Message | Lincoln Yeoh | 2002-04-03 15:13:31 | Sorting. Re: Re : Solaris Performance - Profiling (Solved) |
Previous Message | mlw | 2002-04-03 15:02:15 | Re: Suggestions please: names for function cachability attributes |