Re: NOTIFY and pg_notify performance when deduplicating notifications

From: Catalin Iacob <iacobcatalin(at)gmail(dot)com>
To: julien(at)jdemoor(dot)com
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: NOTIFY and pg_notify performance when deduplicating notifications
Date: 2018-10-10 15:42:05
Message-ID: CAHg_5gpZnS+R+Ap6ht7FysNU8wxajuQbKj=YwaQJWvCi=ABjvg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 9, 2018 at 2:17 PM <julien(at)jdemoor(dot)com> wrote:
> I just caught an error in my patch, it's fixed in the attachment. The 'never' and 'maybe' collapse modes were mixed up in one location.

Here's a partial review of this version, did not read the doc part
very carefully.

First of all, I agree that this is a desirable feature as, for a large
number of notiifications, the O(n^2) overhead quickly becomes very
noticeable.

I would expect the collapse mode to be an enum which is created from
the string early on during parsing and used for the rest of the code.
Instead the string is used all the way leading to string comparisons
in the notification dispatcher and to the need of hardcoding special
strings in various places, including the contrib module.

This comment in the beginning of async.c should also be updated:
* Duplicate notifications from the same transaction are sent out as one
* notification only. This is done to save work when for example a trigger

pg_notify_3args duplicates pg_notify, I would expect a helper function
to be extracted and called from both.

There are braces placed on the same line as the if, for example if
(strlen(collapse_mode) != 0) { which seems to not be the project's
style.

>
> I can't find a reasonable way to build a regression test that checks whether notifications are effectively deduplicated. The output of the LISTEN command lists the PID of the notifying backend for each notification, e.g. : 'Asynchronous notification "foobar" received from server process with PID 24917'. I can't just add this to async.out. I did test manually for all eight combinations : four collapse mode values (missing, empty string, 'maybe' and 'never'), both with NOTIFY and pg_notify().

One way could be to take inspiration from
src/test/isolation/specs/async-notify.spec and check that
pg_notification_queue_usage() does grow when repeating the same
payload with collapse_mode='never' (while for always it would grow).
But I'm not sure it's worth the effort.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Catalin Iacob 2018-10-10 15:46:35 Re: NOTIFY and pg_notify performance when deduplicating notifications
Previous Message Dmitry Dolgov 2018-10-10 15:34:27 Re: Index Skip Scan