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. 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? -- Michael
signature.asc
Description: PGP signature
