-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
> I am prototyping a system which sends all INSERT/UPDATE/DELETE events
> to a third party software, I do:
...
> CREATE OR REPLACE RULE send_notify AS ON INSERT TO log DO
> ALSO NOTIFY logevent;
This is better off as a statement-level trigger, so you won't have
to issue one notify per insert, but one per group of inserts.
It also looks like you might be reinventing a wheel - maybe can you do
what you want with Slony's log shipping?
> When I inserted data to TABLE data with the rate of about 25 every
> second, the client can receive the notifies without any problem, and
> when I use 3 similar programs to feed data, which means about 75
> events every second, I found that Postgres didn't send NOTIFY
> opportunely, since the client do SELECT query every several hundreds
> seconds, which is too long to be acceptable.
>
> So what I want to know is, is there anything wrong with my idea? and
> how frequence can LISTEN/NOTIFY support? Thanks.
The question is, how often does the other side need to get notified? If
things are coming in that fast, there is no need for the client to
check for notifies, just have it continously poll your log table.
We can probably answer your question better if it were clearer what your
program is doing and where it is failing, particularly this bit:
"the client do SELECT query every several hundreds seconds"
- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201002010912
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAktm4f8ACgkQvJuQZxSWSshLUQCg2/TLbE0L8o6SncclQg3eNtVX
UUsAnjRx9Ki6j0ATebUqTXjEs9zMrQIu
=1cnk
-----END PGP SIGNATURE-----
