Re: Performance of the listen command - Mailing list pgsql-general

From Flemming Frandsen
Subject Re: Performance of the listen command
Date
Msg-id 44CC88D8.5070506@partyticket.net
Whole thread Raw
In response to Re: Performance of the listen command  (Christopher Browne <cbbrowne@acm.org>)
Responses Re: Performance of the listen command  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-general
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


pgsql-general by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Joining dates/times (was Re: Splitting Timestamps)
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Corrupted DB? could not open file pg_clog/####