On Wed, Nov 04, 2026 at 04:10:08PM -0800, Lukas Fittl wrote: > Basically the original approach on this thread here is ugly, but it > works, doesn't have performance impact, and is easy to reason about. > I'm advocating for getting this in to both master and the back > branches, and then separately work on solving it more elegantly, which > in my perspective makes most sense in combination with the stack-based > instrumentation thread you linked.
It still feels itchy because that's still abusing of what I think should not be the definition of pgWalUsage, and it's a workaround. I'm wondering if Andres' extra argument about just breaking pgWalUsage to not include worker data would not be the best move, actually, even on stable branches.. That feels risky, still simpler logic links to a simpler definition of these objects, not mixing more concepts into them. > As it stands the other thread on stack-based instrumentation does not > solve this problem (yet), but it contains the prerequisite > infrastructure that's needed, because it avoids the global counters > (pgWalUsage, etc) that move forward as activity happens, and instead > records into the current stack entry that then accumulates into the > parent separately on query end. I'm working on an updated version for > that thread that illustrates how that helps us with the problem at hand. Ah, OK. Good to now, even if that does not address the double counting. -- Michael
signature.asc
Description: PGP signature
