Gavin Sherry wrote: > On Wed, 3 Apr 2002, Mikhail Terekhov wrote: >> >>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? > > There is already a TODO item to address this. But row reuse is the wrong > solution to the problem. See below. >
It is not a solution to the whole LISTEN/NOTIFY problem, but it is a solution to the dead tuples accumulation. > >> >>>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? >> > > Shared memory is much easier and, to all intents and purposes, as reliable > for this kind of usage. It is much faster and is the-right-way-to-do-it. > That highly depends on WHAT-you-want-to-do :) If the new shared memory implementation will guarantee message delivery at the same degree as current implementation then it is the-right-way-to-do-it. If not then let's not broke existing functionality! Let's implement it as an additional functionality, say FASTNOTIFY or RIGHTNOTIFY ;) > > I don't believe that the question 'what happens if there is a buffer > overrun?' is a valid criticism of this approach. In the case of the > backend cache invalidation system, the backends just blow away their cache Forgive my ignorance, you mean sending backend? > to be on the safe side. A buffer overrun (rare as it would be, Regards, Mikhail ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
