Horton

Re: SLRU statistics

Tomas Vondra <tomas.vondra@2ndquadrant.com>

View thread
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: "tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2020-01-21T13:59:51Z
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:

On Tue, Jan 21, 2020 at 06:24:29AM +0000, tsunakawa.takay@fujitsu.com
wrote:
>From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
>> You're right the users can't really take advantage of this - my
>> primary motivation was providing a feedback for devs, benchmarking
>> etc. That might have been done with DEBUG messages or something, but
>> this seems more convenient.
>
>Understood.  I'm in favor of adding performance information even if it
>doesn't make sense for users (like other DBMSs sometimes do.)  One
>concern is that all the PostgreSQL performance statistics have been
>useful so far for tuning in some way, and this may become the first
>exception.  Do we describe the SLRU stats view in the manual, or hide
>it only for PG devs and support staff?
>

Yes, the pg_stat_slru view should be described in a manual. That's
missing from the patch.

>
>> I think it's unclear how desirable / necessary it is to allow users
>> to tweak those caches. I don't think we should have a GUC for
>> everything, but maybe there's some sort of heuristics to determine
>> the size. The assumption is we actually find practical workloads
>> where the size of these SLRUs is a performance issue.
>
>I understood that the new performance statistics are expected to reveal
>what SLRUs need to be tunable and/or implemented with a different
>mechanism like shared buffers.
>

Right. It's certainly meant to provide information for further tuning.
I'm just saying it's targeted more at developers, at least initially.
Maybe we'll end up with GUCs, maybe we'll choose other approaches for
some SLRUs. I don't have an opinion on that yet.


regards

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