On Mon, Nov 16, 2009 at 4:41 PM, Joachim Wieland <j...@mcknight.de> wrote: > On Sat, Nov 14, 2009 at 11:06 PM, Merlin Moncure <mmonc...@gmail.com> wrote: >> The old method (measured on a 4 core high performance server) has >> severe scaling issues due to table bloat (we knew that): >> ./pgbench -c 10 -t 1000 -n -b listen.sql -f notify.sql >> run #1 tps = 1364.948079 (including connections establishing) > >> new method on my dual core workstation (max payload 128): >> ./pgbench -c 10 -t 10000 -n -b listen.sql -f notify.sql -hlocalhost postgres >> tps = 16343.012373 (including connections establishing) > > That looks fine and is similar to my tests where I also see a > performance increase of about 10x, and unlike pg_listener it is > constant.
old method scaled (badly) on volume of notifications and your stuff seems to scale based on # of client's sending simultaneous notifications. Well, you're better all day long, but it shows that your fears regarding locking were not completely unfounded. Do the Burcardo people have any insights on the #of simultaneous notifies are generated from different backends? merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
