SLRU statistics - Mailing list pgsql-hackers

From Tomas Vondra
Subject SLRU statistics
Date
Msg-id 20200119143707.gyinppnigokesjok@development
Whole thread Raw
Responses RE: SLRU statistics
List pgsql-hackers
Hi,

One of the stats I occasionally wanted to know are stats for the SLRU
stats (we have couple of those - clog, subtrans, ...). So here is a WIP
version of a patch adding that.

The implementation is fairly simple - the slru code updates counters in
local memory, and then sends them to the collector at the end of the
transaction (similarly to table/func stats). The collector stores it
similarly to global stats. And the collected stats are accessible
through pg_stat_slru.

The main issue is that we have multiple SLRU caches, and it seems handy
to have separate stats for each. OTOH the number of SLRU stats is not
fixed, so e.g. extensions might define their own SLRU caches. But
handing dynamic number of SLRU caches seems a bit hard (we'd need to
assign some sort of unique IDs etc.) so what I did was define a fixed
number of SLRU types

     typedef enum SlruType
     {
         SLRU_CLOG,
         SLRU_COMMIT_TS,
         SLRU_MULTIXACT_OFFSET,
         SLRU_MULTIXACT_MEMBER,
         SLRU_SUBTRANS,
         SLRU_ASYNC,
         SLRU_OLDSERXID,
         SLRU_OTHER
     } SlruType;

with one group of counters for each group. The last type (SLRU_OTHER) is
used to store stats for all SLRUs that are not predefined. It wouldn't
be that difficult to store dynamic number of SLRUs, but I'm not sure how
to solve issues with identifying SLRUs etc. And there are probably very
few extensions adding custom SLRU anyway.

The one thing missing from the patch is a way to reset the SLRU stats,
similarly to how we can reset bgwriter stats.


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: remove separate postgres.(sh)description files
Next
From: Justin Pryzby
Date:
Subject: Re: should crash recovery ignore checkpoint_flush_after ?