Re: Notifications within triggers seem to compromise performance

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

In response to

Responses

Browse pgsql-performance by date

  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