Hi, On Wed, Mar 19, 2025 at 02:26:47PM +0900, Michael Paquier wrote: > On Wed, Mar 19, 2025 at 09:53:16AM +0800, Xuneng Zhou wrote: > > 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. > > Hmm, yeah, perhaps this is acceptable. The changes in pgstat.c seem > inconsistent, though, only moving the min interval while the max and > idle times stay around.
That's right. OTOH that sounds weird to move the others 2: that would create wider visibility for them without real needs. That's not a big issue, but could impact extensions or friends that would start using those should we change their values in the future. Another option could be to create a dedicated one in walsender.c but I'm not sure I like it more. > This also make me wonder if we should work towards extending > pgstat_report_stat(), so as we save in GetCurrentTimestamp() while > making the internals still local to pgstat.c. Or perhaps not in the > scope of a backpatchable design. I see. I think I'd vote for making the same changes on HEAD and the STABLE branches as a first step. And then think about a new "design" that could be part of the ideas suggested by Andres in [1]. Thoughts? Regards, [1]: https://www.postgresql.org/message-id/erpzwxoptqhuptdrtehqydzjapvroumkhh7lc6poclbhe7jk7l%40l3yfsq5q4pw7 -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
