[EMAIL PROTECTED] (Hannu Krosing) writes: > It also seems that Slony can be modified to not use LISTEN/NOTIFY in > high load situations (akin to high performance network cards, which > switch from interrupt driven mode to polling mode if number of packets > per second reaches certain thresolds).
Yeah, I want to do some more testing of that; it should be easy to improve the "abuse" of pg_listener a whole lot. > Unfortunately Slony and Listen/Notify is not the only place where > high- update rate tables start to suffer from vacuums inability to > clean out dead tuples when working in parallel with other slower > vacuums. In real life there are other database tasks which also need > some tables to stay small, while others must be huge in order to > work effectively. Putting small and big tables in different > databases and using dblink-like functionality when accessing them is > one solution for such cases, but it is rather ugly :( That eliminates the ability to utilize transactions on things that ought to be updated in a single transaction... -- output = ("cbbrowne" "@" "ntlug.org") http://cbbrowne.com/info/lsf.html MS-Windows: Proof that P.T. Barnum was correct. ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster