On Wed, Nov 04, 2026 at 12:50:33PM -0800, Lukas Fittl wrote: > Ack, thanks for chiming in - I'll await for Michael to take another > look but will otherwise post an updated v2 addressing Bertrand's > comments, staying on the (1) approach.
Is that referring to the patch set posted here? I mean here: https://www.postgresql.org/message-id/CAP53Pkwd6Gd4OL6cgh449wtdznWitz_V%3D-PRoswLHOzsMbcftA%40mail.gmail.com >> I think we really ought to make all access by extensions (be it our own or >> external ones) go through helper functions to get this kind of >> information. Right now they're way to tied to how we represent this >> information internally. > > Agreed - I think we've actually made good progress on that in 19 with > Instrumentation now having a clear API that is usable outside of > executor instrumentation, so there is less need to read > pgWalUsage/pgBufferUsage directly. A layer of routines may make the contract behind the numbers one gets easier to understand. That could also be combined with things like bitwise flags to decide which parts you'd like to get computed. Just one idea. > The stack-based instrumentation series [1] actually has two prep > patches that drop the remaining direct users of pgBufferUsage to > further clean up the API (it keeps a user of pgWalUsage in > pruneheap.c, which is a special case), after which I think the main > unsolved use case is how we want the instrumentation fed into the > cumulative stats system without directly accessing a global variable. Do the suggestions on the other thread make what is presented on this thread irrelevant? I don't like much what's been sent now on this thread, but I could see myself like something sent on the other thread if my concerns about the numbers and the way they're aggregated for the leader and workers are lifted. I have not looked at what you have sent on the other thread, just what you have sent on this thread. -- Michael
signature.asc
Description: PGP signature
