Re: Performance of the listen command

Christopher Browne wrote:
> There's a demerit:
> c) If there are a LOT of events, that might not fit in memory nicely.

If you have that many events then the current implementation is going to
suck hard as well:)

Keeping the listener structure in memory wouldn't be too bad.

I'd guess that each connection that listens only needs a single
transaction pointer (64bit int or somesuch?) to point to the transaction
that it has caught up with.

Each transaction will need some way of recording what events were seen,
like:

* a bitmap of the events seen during that transaction (to be useful
you'd need a global string->bit table, this needs some way of
sharing/locking that global datastructure though).

* an ordered list of events seen to allow a simple binary search.
* a more complicated datastructure like a JudySL array

If you really want to save space then a lump of the pr-transaction
bitmaps can be merged if there are no listeners that point to those
transactions.

>>Any ideas, other than run VACUUM pg_listener every 10 minutes?
>
> Remarkably enough, that is exactly the solution that the Slony-I,
> which makes use of LISTEN/NOTIFY, uses. The Slony-I cleanup thread
> vacuums pg_listener (and some other tables) every 10 minutes.

Damnit, I thought I was kidding:)

--
Regards Flemming Frandsen - http://dion.swamp.dk - YAPH