From: | Xuneng Zhou <xunengzhou(at)gmail(dot)com> |
---|---|
To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz> |
Subject: | Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits |
Date: | 2025-03-19 01:53:16 |
Message-ID: | CABPTF7VaVj+BnMyW5-VpGaZPJKpKjKhU8yfmCG2KyR0+mKaYOA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Zhijie Hou (Fujitsu) | 2025-03-19 02:00:27 | RE: Proposal: Deferred Replica Filtering for PostgreSQL Logical Replication |
Previous Message | Andres Freund | 2025-03-19 01:50:11 | Re: AIO v2.5 |