Inefficiency in SLRU stats collection - Mailing list pgsql-hackers

From Tom Lane
Subject Inefficiency in SLRU stats collection
Date
Msg-id 3618.1589313035@sss.pgh.pa.us
Whole thread Raw
Responses Re: Inefficiency in SLRU stats collection  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List 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 by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Our naming of wait events is a disaster.
Next
From: Laurenz Albe
Date:
Subject: Re: COPY, lock release and MVCC