Re: SLRU statistics

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Masahiko Sawada <masahiko.sawada@2ndquadrant.com>, "tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2020-05-14T19:45:26Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix async.c to not register any SLRU stats counts in the postmaster.

  2. Use proper GetDatum function in pg_stat_get_slru().

  3. Initialize SLRU stats entries to zero.

  4. Remove pg_xact from pg_stat_reset_slru docs

  5. Remove pg_xact entry from SLRU stats

  6. Track SLRU page hits in SimpleLruReadPage_ReadOnly

  7. Fix typo in SLRU stats documentation

  8. Collect statistics about SLRU caches

  9. Simplify and rename some GUC variables, per various recent discussions:

Robert Haas <robertmhaas@gmail.com> writes:
> I'm confused by why SLRU statistics are reported by messages sent to
> the stats collector rather than by just directly updating shared
> memory.

It would be better to consider that as an aspect of the WIP stats
collector redesign, rather than inventing a bespoke mechanism for
SLRU stats that's outside the stats collector (and, no doubt,
would have its own set of bugs).  We don't need to invent even more
pathways for this sort of data.

			regards, tom lane