Re: [PATCH] Refactoring of LWLock tranches

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [PATCH] Refactoring of LWLock tranches
Дата
Msg-id CA+TgmoaGh9qwCLNdg4KTa_xtn27n7GAxBV3Z9XJ-Zq88-Po9XA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Refactoring of LWLock tranches  (Andres Freund <andres@anarazel.de>)
Ответы Re: [PATCH] Refactoring of LWLock tranches
Список pgsql-hackers
On Thu, Nov 19, 2015 at 11:30 AM, Andres Freund <andres@anarazel.de> wrote:
> On November 19, 2015 8:09:38 AM PST, Robert Haas <robertmhaas@gmail.com> wrote:
>>On Thu, Nov 19, 2015 at 9:04 AM, Ildus Kurbangaliev
>><i.kurbangaliev@postgrespro.ru> wrote:
>>> The moving base tranches to shared memory has been discussed many
>>times.
>>> The point is using them later in pg_stat_activity and other
>>monitoring
>>> views.
>>
>>I'm not in agreement with this idea.  Actually, I'd prefer that the
>>tranches live in backend-private memory, not shared memory, so that we
>>could for example add backend-local counters to them if desired.
>
> I don't buy that argument. It'd be nearly trivial to have a backend_tranchestats array, indexed by the tranche id,
forsuch counters. 

Hmm, true.

> It's really not particularly convenient to allocate tranches right now. You have to store at least the identifier in
sharedmemory and then redo the registration in each process. Otherwise some processes can't identify them. Which of
ratherinconvenient of you want to register some at runtime 

Sure, that's why we're proposing to use an enum or a list of #defines
for that.  I don't see a need to do any more than that.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [DESIGN] ParallelAppend
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Using quicksort for every external sort run