Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits
| От | Xuneng Zhou |
|---|---|
| Тема | Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits |
| Дата | |
| Msg-id | CABPTF7VaVj+BnMyW5-VpGaZPJKpKjKhU8yfmCG2KyR0+mKaYOA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>) |
| Ответы |
Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits
|
| Список | pgsql-hackers |
Hi,
I am OK with PGSTAT_MIN_INTERVAL. It has been used for flushing other statistics as well. And monitoring systems are generally configured to poll at one-second or longer intervals.
I think that reporting at PGSTAT_MIN_INTERVAL is fine and more than enough. I
mean, I 'm not sure that there is a real use case to query the statistics related
view at more than a second interval anyway.
I think these two conditions are good too. In a busy system, they are met frequently, so the flush routine will be executed at least once every second. Conversely, when WAL generation is low, there's simply less data to record, and the flush frequency naturally decreases.
Or are you concerned that we may not
enter the "When the WAL sender is caught up or has pending data to send" frequently
enough?
> Based on my tests, using PGSTAT_MIN_INTERVAL seems to
> provide a better balance than PGSTAT_IDLE_INTERVAL.
Same here.
В списке pgsql-hackers по дате отправления: