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
|
Список | 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 по дате отправления: