Hi, On Tue, Mar 18, 2025 at 07:14:12PM +0800, Xuneng Zhou wrote: > Hi, > > I performed some tests using elog
Thanks for the testing! > (no so sure whether this is the proper way > to do it) to monitor the new method. Well that simple enough and that works well if the goal is just to "count" ;-) > Here are the findings: > > • With PGSTAT_MIN_INTERVAL set to 1000ms, the number of flush reports was > reduced to approximately 40–50 during the installcheck test suite. > > • With PGSTAT_IDLE_INTERVAL set to 10000ms, the reports dropped to fewer > than 5. > > • In contrast, the previous approach—flushing after every > WalSndKeepaliveIfNecessary()—resulted in roughly 50,000 flushes. > > This reduction is significant, so the overhead from the flush reports is no > longer a concern. Yeah I did observe and do think the same. > However, we still need to determine whether this > frequency is sufficient to capture the system’s state during periods of > high WAL activity. 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. 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. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
