"Dmitry Koterov" <dmitry at koterov.ru> writes:
> So, if anybody reads from sl_log_status, it blocks until anything is
> written to sl_log_status. Seems it will be fully transparent for
> Slony, but decreases the amount of polling queries. (It is an idea
> only, practical implementation may need to be more detailed.) What
> do you think about it?

It smells to me as though you're trying to optimize the wrong problem.

The "pg_listener problem" is one that changes in 1.2 *mostly*
rectifies; the costs associated with NOTIFY/LISTEN should be dropped
to a dull roar in 1.2.  (There are further optimizations in CVS HEAD,
but it shouldn't be *highly* relevant.)

What hasn't been touched, and in a sense, can't be, is to reduce the
load of processing the queries against the "master" node that pull
replication data to feed to the subscribers.

I suspect that it is THOSE queries that are causing you trouble, as
opposed to anything about NOTIFY/LISTEN.

If you have nine nodes all feeding off the master, that's going to put
considerable load on the master node.  And THAT would easily cause
things to slow down on the master, and cause replicas to lag.

The fewer nodes that feed directly from the origin, the less load that
you put on the origin, and the easier it should be able to feed them.
-- 
select 'cbbrowne' || '@' || 'ca.afilias.info';
<http://dba2.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)