RE: SLRU statistics

Поиск
Список
Период
Сортировка
От tsunakawa.takay@fujitsu.com
Тема RE: SLRU statistics
Дата
Msg-id OSAPR01MB50730B73FD983C73DD74CD76FE0D0@OSAPR01MB5073.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: SLRU statistics  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: SLRU statistics
Список pgsql-hackers
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
sometimesdo.)  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
devsand support staff? 


> 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
implementedwith a different mechanism like shared buffers. 


Regards
Takayuki Tsunakawa






В списке pgsql-hackers по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: error context for vacuum to include block number
Следующее
От: Fujii Masao
Дата:
Сообщение: Minor issues in .pgpass