Re: Notifications within triggers seem to compromise performance

From: Grégoire de Turckheim <gdeturckheim(at)scaleway(dot)com>
To: pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Re: Notifications within triggers seem to compromise performance
Date: 2019-10-28 16:35:22
Message-ID: fbafc656-ca6f-0b94-7dff-37eeb937df7f@scaleway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Le 28/10/2019 à 17:25, Tom Lane a écrit :
> =?UTF-8?Q?Gr=c3=a9goire_de_Turckheim?= <gdeturckheim(at)scaleway(dot)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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Craig James 2019-10-28 22:40:58 UNION causes horrible plan on JOIN
Previous Message Tom Lane 2019-10-28 16:25:25 Re: Notifications within triggers seem to compromise performance