Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1aS679-0003wA-90 for pgsql-hackers@arkaria.postgresql.org; Sat, 06 Feb 2016 16:53:39 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1aS678-0006j8-S8 for pgsql-hackers@arkaria.postgresql.org; Sat, 06 Feb 2016 16:53:38 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1aS65p-0004zx-8S for pgsql-hackers@postgresql.org; Sat, 06 Feb 2016 16:52:17 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1aS65n-0005jy-D9 for pgsql-hackers@postgresql.org; Sat, 06 Feb 2016 16:52:16 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id u16GqBbn010637; Sat, 6 Feb 2016 11:52:11 -0500 From: Tom Lane To: Brendan Jurd cc: Robert Haas , =?UTF-8?Q?Filip_Rembia=C5=82kowski?= , Pgsql Hackers Subject: Re: proposal: make NOTIFY list de-duplication optional In-reply-to: References: <7647.1454723392@sss.pgh.pa.us> Comments: In-reply-to Brendan Jurd message dated "Sat, 06 Feb 2016 13:35:40 +0000" Date: Sat, 06 Feb 2016 11:52:11 -0500 Message-ID: <10636.1454777531@sss.pgh.pa.us> X-Pg-Spam-Score: -2.3 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Brendan Jurd writes: > On Sat, 6 Feb 2016 at 12:50 Tom Lane wrote: >> Yeah, I agree that a GUC for this is quite unappetizing. > How would you feel about a variant for calling NOTIFY? If we decide that this ought to be user-visible, then an extra NOTIFY parameter would be the way to do it. I'd much rather it "just works" though. In particular, if we do start advertising user control of de-duplication, we are likely to start getting bug reports about every case where it's inexact, eg the no-checks-across-subxact-boundaries business. > Optimising the remove-duplicates path is still probably a worthwhile > endeavour, but if the user really doesn't care at all about duplication, it > seems silly to force them to pay any performance price for a behaviour they > didn't want, no? I would only be impressed with that argument if it could be shown that de-duplication was a significant fraction of the total cost of a typical NOTIFY cycle. Obviously, you can make the O(N^2) term dominate if you try, but I really doubt that it's significant for reasonable numbers of notify events per transaction. One should also keep in mind that duplicate events are going to cost extra processing on the client-application side, too. In my experience with using NOTIFY, that cost probably dwarfs the cost of emitting the messages. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers