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 по дате отправления: