Re: proposal: make NOTIFY list de-duplication optional
От | Filip Rembiałkowski |
---|---|
Тема | Re: proposal: make NOTIFY list de-duplication optional |
Дата | |
Msg-id | CAP_rwwkG5pkGLAXz4h9ax7Qy2oyJNyjJfw6iQyTJvdPTC0TSAA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: proposal: make NOTIFY list de-duplication optional (Craig Ringer <craig@2ndquadrant.com>) |
Ответы |
Re: proposal: make NOTIFY list de-duplication optional
Re: proposal: make NOTIFY list de-duplication optional |
Список | pgsql-hackers |
On Mon, Feb 8, 2016 at 1:52 PM, Craig Ringer <craig@2ndquadrant.com> wrote: > Would it be correct to say that if ALL is specified then a message is queued > no matter what. If DISTINCT is specified then it is only queued if no > message with the same channel and argument is already queued for delivery. Yes, exactly. > Using DISTINCT can never decrease the total number of messages to be sent. This sentence does not sound true. DISTINCT is the default, old behaviour. It *can* decrease total number of messages (by deduplication) > I've found the deduplication functionality of NOTIFY very frustrating in the past > and I see this as a significant improvement. Sometimes the *number of times* > something happened is significant too... yep, same idea here. Here is my next try, after suggestions from -perf and -hackers list: * no GUC * small addition to NOTIFY grammar: NOTIFY ALL/DISTINCT * corresponding, 3-argument version of pg_notify(text,text,bool) * updated the docs to include new syntax and clarify behavior * no hashtable in AsyncExistsPendingNotify (I don't see much sense in that part; and it can be well done separately from this)
Вложения
В списке pgsql-hackers по дате отправления: