Re: Configurable FP_LOCK_SLOTS_PER_BACKEND

On 8/7/23 18:56, Nathan Bossart wrote:
> On Mon, Aug 07, 2023 at 12:51:24PM +0200, Tomas Vondra wrote:
>> The bad news is this seems to have negative impact on cases with few
>> partitions, that'd fit into 16 slots. Which is not surprising, as the
>> code has to walk longer arrays, it probably affects caching etc. So this
>> would hurt the systems that don't use that many relations - not much,
>> but still.
>>
>> The regression appears to be consistently ~3%, and v2 aimed to improve
>> that - at least for the case with just 100 rows. It even gains ~5% in a
>> couple cases. It's however a bit strange v2 doesn't really help the two
>> larger cases.
>>
>> Overall, I think this seems interesting - it's hard to not like doubling
>> the throughput in some cases. Yes, it's 100 rows only, and the real
>> improvements are bound to be smaller, it would help short OLTP queries
>> that only process a couple rows.
>
> Indeed. I wonder whether we could mitigate the regressions by using SIMD
> intrinsics in the loops. Or auto-vectorization, if that is possible.
>

Maybe, but from what I know about SIMD it would require a lot of changes
to the design, so that the loops don't mix accesses to different PGPROC
fields (fpLockBits, fpRelId) and so on. But I think it'd be better to
just stop walking the whole array regularly.

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company