LWLock granular partition lock memory layout - Mailing list pgsql-hackers

From Alexandre Felipe
Subject LWLock granular partition lock memory layout
Date
Msg-id CAE8JnxOGU4pT19z6JRVW9W0inS1cXt_pRPpCN0dAdTueo_GVkg@mail.gmail.com
Whole thread
Responses Re: LWLock granular partition lock memory layout
Re: LWLock granular partition lock memory layout
List pgsql-hackers
This time I am not changing LWLock semantics :)

Consider the a hash table partitioned in two different ways.

1. having S partitions, guarded by LWLocks on the same cache line.
2. having a single LWLock.

Which one will give better concurrency?
Which one will cost more to lock/unlock?

I argue that having S partitions is better in several different ways.

a. Concurrency of LW_EXCLUSIVE
b. Reduced contention on LWLockWaitListLock
c. Reduced CAS iterations in LWLockAtttemptLock
d. Reduced waits (that implies wait list access and sleeping)

I included a (pointless) benchmark result.

And you can find a longer discussion in 0002 patch.


Attachment

pgsql-hackers by date:

Previous
From: Antonin Houska
Date:
Subject: Re: REPACK (CONCURRENTLY) might keep dropped-column data
Next
From: Fujii Masao
Date:
Subject: Re: create table like including storage parameter