Re: scalability bottlenecks with (many) partitions (and more)

On 3/4/25 14:11, Andres Freund wrote:
> Hi,
> 
> On 2025-03-04 14:05:22 +0100, Tomas Vondra wrote:
>> On 3/3/25 21:52, Andres Freund wrote:
>>>> It's not a proper constant, of course, but it seemed close
>>>> enough. Yes, it might confuse people into thinking it's a constant, or
>>>> is there some additional impact?
>>>
>>> That seems plenty. I just looked at the shem sizing function and was confused
>>> because I didn't see where the max_locks_per_transaction affects the
>>> allocation size.
>>>
>>
>> But the shmem sizing doesn't use FP_LOCK_SLOTS_PER_BACKEND at all, both
>> proc.c and postinit.c use the "full" formula, not the macro
> 
> Not sure what I brainfarted there...
> 

This got me thinking - maybe it'd be better to use the new
FastPathLockSlotsPerBackend() in all places that need the number of
slots per backend, including those in proc.c etc.? Arguably, these
places should have used FP_LOCK_SLOTS_PER_BACKEND before.

The attached v2 patch does that.

>>>> The one fix I can think of is making it look more like a function,
>>>> possibly just like this:
>>>>
>>>> #define	FastPathLockSlotsPerBackend() \
>>>>   (FP_LOCK_SLOTS_PER_GROUP * FastPathLockGroupsPerBackend)
>>>>
>>>> Or do you have another suggestion?
>>>
>>> That'd work for me.
>>>
>>
>> Attached is a patch doing this, but considering it has nothing to do
>> with the shmem sizing, I wonder if it's worth it.
> 
> Yes.
> 

OK, barring objections I'll push the v2.


regards

-- 
Tomas Vondra