On Tue, Jan 21, 2020 at 06:24:29AM +0000, tsunakawa.ta...@fujitsu.com
wrote:
From: Tomas Vondra <tomas.von...@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
