Re: Reducing contention for the LockMgrLock

Tom Lane wrote:

Interesting proposal.

> LockReleaseAll is also interesting from a performance point of view,
> since it executes at every transaction exit. If we divide PGPROC's
> PROCLOCK list into N lists then it will be very easy for LockReleaseAll
> to take only the partition locks it actually needs to release these locks;
> if not, we might have to resort to scanning the list N times, once while
> we hold the LWLock for each partition.

On the other hand, each scan would be shorter than the previous one; and
it's not necessary to hold each and every partition's LWLock, only the
one found in the first entry of the list on each scan until the list is
empty. So it's N scans only in the worst case of a PGPROC holding locks
on all partitions.

> One objection I can see to this idea is that having N lock hash tables
> instead of one will eat a larger amount of shared memory in hashtable
> overhead. But the lock hashtables are fairly small relative to the
> shared buffer array (given typical configuration parameters) so this
> doesn't seem like a major problem.

Is hashtable overhead all that large? Each table could be made
initially size-of-current-table/N entries. One problem is that
currently the memory freed from a hashtable is not put back into shmem
freespace, is it?

> While at it, I'm inclined to get rid of the current assumption that there
> are logically separate hash tables for different LockMethodIds. AFAICS all
> that's doing for us is creating a level of confusion; there's nothing on
> the horizon suggesting we'd ever actually make use of the flexibility.

Yeah, please.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.