Joel Stevenson <joelstevenson@xxxxxxx> writes: > Now that I see a little bit more of what goes on under the hood of > this function I see that it's still basically table-driven and I'll > adjust my expectations accordingly, Yeah, there's been discussion of replacing the implementation with some all-in-memory queue kind of setup, but no one's got round to that yet. > With ps I can see some postgres backends with a 'notify interrupt > waiting' command line during the tests - could it be an issue with > signal handling on the original machine - something entirely outside > of PG's control? No, that's not unexpected if you have the same notify being delivered to multiple processes that had been idle. They'll all get wakened and try to read pg_listener to see what happened, but since this is a read-modify-write type of operation it uses an exclusive lock, so only one can clear its pg_listener entry at a time. The 'waiting' ones you are seeing are stacked up behind whichever one has the lock at the moment. They shouldn't be waiting for long. I'm still baffled by why we aren't seeing comparable performance for the same test case. What I'm testing on is couple-year-old desktop kit (dual 2.8GHz Xeon, consumer-grade disk drive) --- I had assumed your server would be at least as fast as that, but maybe not? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
