Inefficiency in SLRU stats collection

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Inefficiency in SLRU stats collection
Дата
Msg-id 3618.1589313035@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: Inefficiency in SLRU stats collection  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список pgsql-hackers
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.)

This does require the assumption that all backends agree
on the SLRU stats index for a particular SLRU cache.  But
AFAICS we're locked into that already, since the backends
use those indexes to tell the stats collector which cache
they're sending stats for.

Thoughts?

            regards, tom lane



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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Our naming of wait events is a disaster.
Следующее
От: Laurenz Albe
Дата:
Сообщение: Re: COPY, lock release and MVCC