On Fri, May 17, 2024 at 04:25:15PM -0400, Robert Haas wrote: > On Fri, May 17, 2024 at 4:20 PM Jeff Davis <pg...@j-davis.com> wrote: >> Regarding this particular change: the checkpointing hook seems more >> like a table AM feature, so I agree with you that we should have a good >> idea how a real table AM might use this, rather than only >> pg_stat_statements. > > I would even be OK with a pg_stat_statements example that is fully > working and fully explained. I just don't want to have no example at > all. The original proposal has been changed twice because of > complaints that the hook wasn't quite useful enough, but I think that > only proves that v3 is closer to being useful than v1. If v1 is 40% of > the way to useful and v3 is 120% of the way to useful, wonderful! But > if v1 is 20% of the way to being useful and v3 is 60% of the way to > being useful, it's not time to commit anything yet. I don't know which > is the case, and I think if someone wants this to be committed, they > need to explain clearly why it's the first and not the second.
Please note that I've been studying ways to have pg_stat_statements being plugged in directly with the shared pgstat APIs to get it backed by a dshash to give more flexibility and scaling, giving a way for extensions to register their own stats kind. In this case, the flush of the stats would be controlled with a callback in the stats registered by the extensions, conflicting with what's proposed here. pg_stat_statements is all about stats, at the end. I don't want this argument to act as a barrier if a checkpoint hook is an accepted consensus here, but a checkpoint hook used for this code path is not the most intuitive solution I can think of in the long-term. -- Michael
signature.asc
Description: PGP signature
