On Fri, Feb 19, 2016 at 10:09 PM, Catalin Iacob <iacobcata...@gmail.com>
> On 2/9/16, Tom Lane <t...@sss.pgh.pa.us> wrote:
> > FWIW, I think it would be a good thing if the NOTIFY statement syntax
> > not remarkably different from the syntax used in the pg_notify() function
> > call. To do otherwise would certainly be confusing. So on the whole
> > I'd go with the "NOTIFY channel [ , payload [ , mode ] ]" option.
> I'm quite interested in getting this addressed in time for 9.6 as I'll
> be using NOTIFY extensively in a project and I agree with Craig that
> the deduplication is frustrating both because you sometimes want every
> event and because it can apparently cause O(n^2) behaviour (which I
> didn't know before this thread). If another use case for suppressing
> deduplication is needed, consider publishing events like "inserted
> tuple", "deleted tuple" from triggers and a transaction that does
> "insert, delete, insert" which the client then sees as "insert,
> delete, oops nothing else".
> Tom's proposal allows for more flexible modes than just the ALL and
> DISTINCT keywords and accommodates the concern that DISTINCT will lead
> to bug reports about not really being distinct due to savepoints.
> Android has a similar thing for push notifications to mobile devices
> which they call collapse:
> https://developers.google.com/cloud-messaging/concept-options, search
> for collapse_key.
> So I propose NOTIFY channel [ , payload [ , collapse_mode ] ] with
> collapse mode being:
> * 'never'
> ** Filip's proposed behaviour for the ALL option
> ** if specified, every notification is queued regardless what's in the
> * 'maybe'
> ** vague word allowing for flexibility in what the server decides to do
> ** current behaviour
> ** improves performance for big transactions if a row trigger
> creates the same payload over and over one after the other due to the
> current optimization of checking the tail of the list
> ** has performance problems O(n^2) for big transactions with
> different payloads
> *** the performance problems can be addressed by a different
> patch which uses a hash table, or decides to collapse less
> aggressively (Tom's check last 100 idea), or whatever else
> *** in the meantime the 'never' mode acts as a good workaround
> In the future we might support an 'always' collapse_mode which would
> really be always, including across savepoints. Or an
> 'only_inside_savepoints' which guarantees the current behaviour.
> Filip, do you agree with Tom's proposal? Do you plan to rework the
> patch on these lines? If you are I'll try to review it, if not I could
> give it a shot as I'm interested in having this in 9.6.
I see that Tom's remarks give more flexibility, and your refinement makes
I was stuck because both syntaxes have their ugliness. NOTIFY allows the
payload to be NULL:
How would this look like in "never" mode?
NOTIFY chan01, NULL, 'never'; -- seems very cryptic.