hannu@skype.net (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.