RE: NOTIFY and pg_notify performance when deduplicating notifications
Вложения
В списке pgsql-hackers по дате отправления:
| От | |
|---|---|
| Тема | RE: NOTIFY and pg_notify performance when deduplicating notifications |
| Дата | |
| Msg-id | 028301d45fca$020595e0$0610c1a0$@jdemoor.com обсуждение |
| Ответ на | Re: NOTIFY and pg_notify performance when deduplicating notifications (Catalin Iacob <iacobcatalin@gmail.com>) |
| Ответы |
Re: NOTIFY and pg_notify performance when deduplicating notifications
|
| Список | pgsql-hackers |
> Indeed, I have the same and am very interested in this. > > > I hope this patch can be reviewed and included in PostgreSQL. > > I added this to the next Commitfest and added myself as a reviewer. > Will try to a review beginning of next week. > https://commitfest.postgresql.org/20/1820/ Thank you for reviewing. I just caught an error in my patch, it's fixed in the attachment. The 'never' and 'maybe' collapse modes were mixed up inone location. 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. : 'Asynchronousnotification "foobar" received from server process with PID 24917'. I can't just add this to async.out. I didtest manually for all eight combinations : four collapse mode values (missing, empty string, 'maybe' and 'never'), bothwith NOTIFY and pg_notify().
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера