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,
* 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
>>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
In response to
pgsql-general by date
|Next:||From: Martijn van Oosterhout||Date: 2006-07-30 10:31:11|
|Subject: Re: Corrupted DB? could not open file pg_clog/####|
|Previous:||From: Martijn van Oosterhout||Date: 2006-07-30 10:20:41|
|Subject: Re: Joining dates/times (was Re: Splitting Timestamps)|