Re: Custom pgstat support performance regression for simple queries

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