Joel Stevenson <joelstevenson@xxxxxxx> writes: > What's really baffling is that there are plenty of other OLTP queries > going in multiple backends simultaneously that don't fall over my > 300ms query log threshold, and yet NOTIFY and LISTEN consistently do. > What's more it's looks like it's only happening for registered > listener relnames. Hmm, that says that it's not a matter of locking on pg_listener, but of actually applying the row update(s) and/or signaling the recipient(s). If you're not seeing performance issues for ordinary table-update operations it's hard to see why pg_listener updates would be any worse, so that seems to point the finger at the signaling. Which is just a matter of a kill(2) and shouldn't be that expensive. It might be interesting to try strace'ing the whole PG process tree while these notifies are going on, and seeing if you can identify any specific kernel calls that seem to take a long time. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
