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

Hi,

Here's a bit more polished version of this patch series. I only propose
0001 and 0002 for eventual commit, the two other bits are just stuff to
help with benchmarking etc.

0001
----
increases the size of the arrays, but uses hard-coded number of groups
(64, so 1024 locks) and leaves everything in PGPROC

0002
----
Allocates that separately from PGPROC, and sets the number based on
max_locks_per_transactions

I think 0001 and 0002 should be in fairly good shape, IMO. There's a
couple cosmetic things that bother me (e.g. the way it Asserts after
each FAST_PATH_LOCK_REL_GROUP seems distracting).

But other than that I think it's fine, so a review / opinions would be
very welcome.

0003
----
Adds a separate GUC to make benchmarking easier (without the impact of
changing the size of the lock table).

I think the agreement is to not have a new GUC, unless it turns out to
be necessary in the future. So 0003 was just to make benchmarking a bit
easier.

0004
----
This was a quick attempt to track the fraction of fast-path locks, and
adding the infrastructure is mostly mechanical thing. But it turns out
it's not quite trivial to track why a lock did not use fast-path. It
might have been because it wouldn't fit, or maybe it's not eligible, or
maybe there's a stronger lock. It's not obvious how to count these to
help with evaluating the number of fast-path slots.

regards

--
Tomas Vondra