Hi, On 2025-07-23 09:54:12 +0900, Michael Paquier wrote: > On Tue, Jul 22, 2025 at 10:57:06AM -0400, Andres Freund wrote: > > It seems rather unsurprising that that causes a slowdown. > > > > The pre-check is there to: > > /* Don't expend a clock check if nothing to do */ > > > > but you made it way more expensive than a clock check would have been (not > > counting old vmware installs or such, where clock checks take ages). > > > > If I change the loop count to only be the builtin stats kinds, the overhead > > goes away almost completely. > > Noted. I was wondering originally if the threshold for the builtin > and custom kinds should be lowered, as well. Perhaps that's just too > optimistic, so we can first lower things. Say PGSTAT_KIND_CUSTOM_MIN > to 32 and PGSTAT_KIND_MAX to 48 or so to begin with? I don't see a > strict policy here, but these would make the whole cheaper to begin > with, with enough margin for any new stats kinds.
Yes, 256 seems pointlessly large. > Then, about the loop used here, I'd be OK to keep the past shortcuts > for the builtin fixed-sized stats kinds with the requirement that new > builtin stats kinds need to hack into pgstat_report_stat() themselves > on efficiency grounds, combined with a second loop for custom kinds, > taken only if pgstat_register_kind() has been used by tracking if > that's the case in a flag. Do you have a specific preference here? I think the downstream approach of having a flag that says if there are *any* pending stats is better. Greetings, Andres Freund
