From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Filip Rembiałkowski <filip(dot)rembialkowski(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: make NOTIFY list de-duplication optional |
Date: | 2016-02-06 17:50:59 |
Message-ID: | 56B63283.4050508@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Shubham Barai | 2016-02-06 17:56:19 | Optimization- Check the set of conditionals on a WHERE clause against CHECK constraints. |
Previous Message | Andres Freund | 2016-02-06 17:49:30 | Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby |