From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Matteo Beccati <php(at)beccati(dot)com>, Postgres Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: DISCARD ALL failing to acquire locks on pg_listen |
Date: | 2009-02-12 20:09:42 |
Message-ID: | 603c8f070902121209s4b0d10eds3706888145fcfe0d@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Feb 12, 2009 at 2:29 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Just for completeness, I attach another form of the patch that I thought
> about for a bit. This adds the ability for UNLISTEN ALL to revert the
> backend to the state where subsequent UNLISTENs don't cost anything.
> This could be of value in a scenario where you have pooled connections
> and just a small fraction of the client threads are using LISTEN. That
> seemed like kind of an unlikely use-case though. The problem is that
> this patch adds some cycles to transaction commit/abort for everyone,
> whether they ever use LISTEN/UNLISTEN/DISCARD or not. It's not a lot of
> cycles, but even so I'm thinking it's not a win overall. Comments?
This is so lightweight I'd be inclined to go for it, even if the use
case is pretty narrow. Do you think you can actually construct a
benchmark where the difference is measurable?
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-02-12 20:33:56 | Re: DISCARD ALL failing to acquire locks on pg_listen |
Previous Message | Rusty Conover | 2009-02-12 20:09:14 | GIST versus GIN indexes for intarrays |