Re: Custom pgstat support performance regression for simple queries

On Wed, Jul 23, 2025 at 12:00:55PM -0400, Andres Freund wrote:
> On 2025-07-23 09:54:12 +0900, Michael Paquier wrote:
>> 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.

I still cannot put my finger on what a good number should be, but I've
settled to something that I think should be good enough for an initial
release:
PGSTAT_KIND_CUSTOM_MIN 128 -> 24
PGSTAT_KIND_MAX 256 -> 32

These numbers mean that we have enough room for 7 more builtins kinds,
same for custom kinds. Even if this is an issue, this could always be
moved up at some point even across major releases, even if that would
mean for extension developers to switch to a different ID.

>> 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.

Works for me. I am finishing with the attached, meaning that
workloads that trigger no stats can take the fast-exit path with a
single boolean check. What do you think?
--
Michael