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
