Re: Inefficiency in SLRU stats collection

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: Inefficiency in SLRU stats collection
Дата
Msg-id 036e4c48-c09b-9105-d4ce-27bf3bc58476@oss.nttdata.com
обсуждение исходный текст
Ответ на Re: Inefficiency in SLRU stats collection  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список pgsql-hackers

On 2020/05/13 11:26, Kyotaro Horiguchi wrote:
> At Tue, 12 May 2020 15:50:35 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in
>> I happened to come across this code added by 28cac71bd:
>>
>> static PgStat_MsgSLRU *
>> slru_entry(SlruCtl ctl)
>> {
>>      int        idx = pgstat_slru_index(ctl->shared->lwlock_tranche_name);
>>
>>      Assert((idx >= 0) && (idx < SLRU_NUM_ELEMENTS));
>>
>>      return &SLRUStats[idx];
>> }
>>
>> which is invoked by all the pgstat_count_slru_XXX routines.
>> This seems mightily inefficient --- the count functions are
>> just there to increment integer counters, but first they
>> have to do up to half a dozen strcmp's to figure out which
>> counter to increment.
>>
>> We could improve this by adding another integer field to
>> SlruSharedData (which is already big enough that no one
>> would notice) and recording the result of pgstat_slru_index()
>> there as soon as the lwlock_tranche_name is set.  (In fact,
>> it looks like we could stop saving the tranche name as such
>> altogether, thus buying back way more shmem than the integer
>> field would occupy.)

Sounds good to me.

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



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

Предыдущее
От: Fujii Masao
Дата:
Сообщение: pgstat_read_statsfiles() and reset timestamp
Следующее
От: Atsushi Torikoshi
Дата:
Сообщение: Add explanations which are influenced by track_io_timing