Re: [UPDATED] A GUC variable to replace PGBE_ACTIVITY_SIZE

Поиск
Список
Период
Сортировка
Искать
От
Heikki Linnakangas
Тема
Re: [UPDATED] A GUC variable to replace PGBE_ACTIVITY_SIZE
Дата
Msg-id
486A2143.4020604@enterprisedb.com
Ответ на
Список
Дерево обсуждения
A GUC variable to replace PGBE_ACTIVITY_SIZE Thomas Lee <tom@vector-seven.com>
Re: A GUC variable to replace PGBE_ACTIVITY_SIZE Neil Conway <neilc@samurai.com>
Re: A GUC variable to replace PGBE_ACTIVITY_SIZE "Heikki Linnakangas" <heikki@enterprisedb.com>
Re: [UPDATED] A GUC variable to replace PGBE_ACTIVITY_SIZE Thomas Lee <tom@vector-seven.com>
Re: [UPDATED] A GUC variable to replace PGBE_ACTIVITY_SIZE "Heikki Linnakangas" <heikki@enterprisedb.com>
Re: [UPDATED] A GUC variable to replace PGBE_ACTIVITY_SIZE Tom Lane <tgl@sss.pgh.pa.us>
Re: [UPDATED] A GUC variable to replace PGBE_ACTIVITY_SIZE "Heikki Linnakangas" <heikki@enterprisedb.com>
Re: [UPDATED] A GUC variable to replace PGBE_ACTIVITY_SIZE Tom Lane <tgl@sss.pgh.pa.us>
Tom Lane wrote:
> "Heikki Linnakangas"  writes:
>> Another simple optimization occurred to me while looking at this: we 
>> should skip the memcpy/strcpy altogether if the BackendActivity slot is 
>> not in use. That seems like a good bet, you usually don't try to max out 
>> max_connections.
> 
> Huh?  How could we be assigning to a slot that is not in use?

Before the patch, we loop through the shared PgBackendStatus slots 
(there is MaxBackends of them), and issue a memcpy for each to copy it 
to our local slot. After that, we check if it was actually in use.

After the patch, we still loop through the shared slots, but only issue 
the memcpy for slots that are in use.

Hope this answers your question, I'm not sure what you meant...

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com
В списке pgsql-patches по дате отправления
От: Heikki Linnakangas
Дата:
От: Tom Lane
Дата:
FAQ