Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1aRs1x-0005l9-2l for pgsql-hackers@arkaria.postgresql.org; Sat, 06 Feb 2016 01:51:21 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1aRs1w-0008M6-Lo for pgsql-hackers@arkaria.postgresql.org; Sat, 06 Feb 2016 01:51:20 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1aRs0a-0006I7-R2 for pgsql-hackers@postgresql.org; Sat, 06 Feb 2016 01:49:56 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1aRs0Y-0004hm-2f for pgsql-hackers@postgresql.org; Sat, 06 Feb 2016 01:49:55 +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 u161nqtQ007648; Fri, 5 Feb 2016 20:49:52 -0500 From: Tom Lane To: Robert Haas cc: =?UTF-8?Q?Filip_Rembia=C5=82kowski?= , Pgsql Hackers Subject: Re: proposal: make NOTIFY list de-duplication optional In-reply-to: References: Comments: In-reply-to Robert Haas message dated "Fri, 05 Feb 2016 19:44:35 -0500" Date: Fri, 05 Feb 2016 20:49:52 -0500 Message-ID: <7647.1454723392@sss.pgh.pa.us> X-Pg-Spam-Score: -2.2 (--) 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 Robert Haas writes: > On Fri, Feb 5, 2016 at 10:17 AM, Filip RembiaƂkowski > wrote: >> - new GUC in "Statement Behaviour" section, notify_duplicate_removal > I agree with what Merlin said about this: > http://www.postgresql.org/message-id/CAHyXU0yoHe8Qc=yC10AHU1nFiA1tbHsg+35Ds-oEueUapo7t4g@mail.gmail.com Yeah, I agree that a GUC for this is quite unappetizing. One idea would be to build a hashtable to aid with duplicate detection (perhaps only once the pending-notify list gets long). Another thought is that it's already the case that duplicate detection is something of a "best effort" activity; note for example the comment in AsyncExistsPendingNotify pointing out that we don't collapse duplicates across subtransactions. Would it be acceptable to relax the standards a bit further? For example, if we only checked for duplicates among the last N notification list entries (for N say around 100), we'd probably cover just about all the useful cases, and the runtime would stay linear. The data structure isn't tremendously conducive to that, but it could be done. 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