Re: Notifications within triggers seem to compromise performance
От | Grégoire de Turckheim |
---|---|
Тема | Re: Notifications within triggers seem to compromise performance |
Дата | |
Msg-id | fbafc656-ca6f-0b94-7dff-37eeb937df7f@scaleway.com обсуждение исходный текст |
Ответ на | Re: Notifications within triggers seem to compromise performance (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-performance |
Le 28/10/2019 à 17:25, Tom Lane a écrit : > =?UTF-8?Q?Gr=c3=a9goire_de_Turckheim?= <gdeturckheim@scaleway.com> writes: >> Le 28/10/2019 à 15:22, Tom Lane a écrit : >>> We made some performance improvements for NOTIFY just a couple months >>> ago, cf commits b10f40bf0, bb5ae8f6c, bca6e6435, 51004c717. It would >>> be interesting to know how much those changes helped your use-case. >> If my understanding of the problem is correct, there is no performance >> issue with the notification itself. >> The problem is the following: a system-wide lock is taken pre-commit, so >> any other transaction with a NOTIFY will have to wait for other >> transactions to complete before it can leave its own pre-commit stage. > Right, but all commits are single-threaded at some granularity. > The big problem with NOTIFY is that it sits for a long time holding > that lock, if you have a lot of notify traffic. The commits I mentioned > should improve that. > > Anyway, as I said, it would be good to find out whether the already > finished fixes are enough to solve your problem, before we debate > whether more needs to be done. Let's do it this way, I'll give it a try (might be long, this isn't something we can easily upgrade) and get back to you. Thanks! -- Grégoire de Turckheim
В списке pgsql-performance по дате отправления: