Subject: Re: proposal: make NOTIFY list de-duplication optional
To: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>
References: 
 <CAP_rwwn2z0gPOn8GuQ3qDVS5+HgEcG2EzEOyiJtcA=vpDEhoCg@mail.gmail.com>
 <CA+TgmoYiKedu0vUXFQHKpJ1COmT7sNJd2KOLLtXQTQc6Ztgkug@mail.gmail.com>
 <7647.1454723392@sss.pgh.pa.us>
Cc: =?UTF-8?Q?Filip_Rembia=c5=82kowski?= <filip.rembialkowski@gmail.com>,
 Pgsql Hackers <pgsql-hackers@postgresql.org>
From: Andrew Dunstan <andrew@dunslane.net>
Message-ID: <56B63283.4050508@dunslane.net>
Date: Sat, 6 Feb 2016 12:50:59 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <7647.1454723392@sss.pgh.pa.us>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


On 02/05/2016 08:49 PM, Tom Lane wrote:

> Yeah, I agree that a GUC for this is quite unappetizing.

Agreed.

>
> 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.
>
> 			


I like the hashtable idea if it can be made workable.

cheers

andrew


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers