On Mon, Nov 16, 2009 at 4:41 PM, Joachim Wieland <joe@mcknight.de> wrote:
> On Sat, Nov 14, 2009 at 11:06 PM, Merlin Moncure <mmoncure@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
