Jeff Janes <jeff.janes@gmail.com> writes:
> On Tue, Sep 13, 2016 at 6:21 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Having said that, the amount of slop involved is only enough for a
>> few hundred lock entries. Not sure how you're managing to get to
>> nearly 20000 extra entries.
> The code assumes every locked object will have 2 processes that hold it (or
> wait for it). If you actually only have one holder for each locked object,
> that frees up a lot of memory to hold more locked objects.
Ah, right, the key is the difference between the init and max table sizes
in InitLocks. So his test case is chewing up all the spare space but more
of it is going into the LOCK table than the PROCLOCK table, compared to
the estimates. Possibly would leave him a bit starved for PROCLOCKs later.
I'm disinclined to change that initialization code though, since the point
is to try to adapt to variations in the holders-per-lock ratio for
different workloads.
regards, tom lane