Re: New statistics for tuning WAL buffer size

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: New statistics for tuning WAL buffer size
Дата
Msg-id 96cd53ad-90b6-26a2-20c6-61ea15270df8@oss.nttdata.com
обсуждение исходный текст
Ответ на RE: New statistics for tuning WAL buffer size  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
Ответы RE: New statistics for tuning WAL buffer size  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
Список pgsql-hackers

On 2020/10/01 10:50, tsunakawa.takay@fujitsu.com wrote:
> From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
>> Another reason that I mildly want to object to subdivided functions is
>> I was annoyed that a stats view makes many individual calls to
>> functions that internally share the same statistics entry.  That
>> behavior required me to provide an entry-caching feature to my
>> shared-memory statistics patch.
> 
> +1
> The views for troubleshooting performance problems should be as light as possible.  IIRC, we saw  frequently
searchingpg_stat_replication consume unexpectedly high CPU power, because it calls pg_stat_get_activity(null) to get
allsessions and join them with the walsenders.  At that time, we had hundreds of client sessions.  We expected
pg_stat_replicationto be very lightweight because it provides information about a few walsenders.
 

I think that we can improve that, for example, by storing backend id
into WalSndCtl and making pg_stat_get_wal_senders() directly
get the walsender's LocalPgBackendStatus with the backend id,
rather than joining pg_stat_get_activity() and pg_stat_get_wal_senders().

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Should walsernder check correctness of WAL records?
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Add information to rm_redo_error_callback()