Re: DISCARD ALL failing to acquire locks on pg_listen

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: DISCARD ALL failing to acquire locks on pg_listen
Дата
Msg-id 603c8f070902121209s4b0d10eds3706888145fcfe0d@mail.gmail.com
обсуждение исходный текст
Ответ на Re: DISCARD ALL failing to acquire locks on pg_listen  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: DISCARD ALL failing to acquire locks on pg_listen
Список pgsql-hackers
On Thu, Feb 12, 2009 at 2:29 PM, Tom Lane <tgl@sss.pgh.pa.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: pg_migrator and handling dropped columns
Следующее
От: Tom Lane
Дата:
Сообщение: Re: DISCARD ALL failing to acquire locks on pg_listen