Re: Custom pgstat support performance regression for simple queries

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