From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Grégoire de Turckheim <gdeturckheim(at)scaleway(dot)com> |
Cc: | pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: Notifications within triggers seem to compromise performance |
Date: | 2019-10-28 16:25:25 |
Message-ID: | 24269.1572279925@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
=?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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Grégoire de Turckheim | 2019-10-28 16:35:22 | Re: Notifications within triggers seem to compromise performance |
Previous Message | Grégoire de Turckheim | 2019-10-28 15:39:30 | Re: Notifications within triggers seem to compromise performance |