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>
Subject: Re: SLRU statistics
Date: Tue, 21 Jan 2020 14:59:51 +0100
Message-ID: <20200121135951.dlmhe2tjpqktfn4b@development> (raw)
In-Reply-To: <OSAPR01MB50730B73FD983C73DD74CD76FE0D0@OSAPR01MB5073.jpnprd01.prod.outlook.com>
References: <20200119143707.gyinppnigokesjok@development>
<OSAPR01MB5073426AFE2F2A524948FA6CFE320@OSAPR01MB5073.jpnprd01.prod.outlook.com>
<20200120163754.mbbkbhzaummlo47c@development>
<OSAPR01MB50730B73FD983C73DD74CD76FE0D0@OSAPR01MB5073.jpnprd01.prod.outlook.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tomas.vondra@2ndquadrant.com, tsunakawa.takay@fujitsu.com
Subject: Re: SLRU statistics
In-Reply-To: <20200121135951.dlmhe2tjpqktfn4b@development>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox