pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedLwLockRelease performance
3+ messages / 3 participants
[nested] [flat]
* LwLockRelease performance
@ 2021-12-01 14:26 Ashkil Dighin <ashkildighin76@gmail.com>
0 siblings, 2 replies; 3+ messages in thread
From: Ashkil Dighin @ 2021-12-01 14:26 UTC (permalink / raw)
To: pgsql-performance@lists.postgresql.org
Hi
The performance bottleneck in LWLockRelease()method goes through an array
one by one to see which lock was released with O(N). As soon as the lock is
found it performs an array to remove the lock.
As linear search and compaction delays the release of the lock forcing the
other Postgres instances WAiting for the lock to be released
Is any possible solution like
1. LWLockRelease() releases the lock first and then remove held lock from
the array
2. Binary search (like non-linear structure) to reduce on high searching
and remove all held locks
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: LwLockRelease performance
@ 2021-12-02 22:19 Tom Lane <tgl@sss.pgh.pa.us>
parent: Ashkil Dighin <ashkildighin76@gmail.com>
1 sibling, 0 replies; 3+ messages in thread
From: Tom Lane @ 2021-12-02 22:19 UTC (permalink / raw)
To: Ashkil Dighin <ashkildighin76@gmail.com>; +Cc: pgsql-performance@lists.postgresql.org
Ashkil Dighin <ashkildighin76@gmail.com> writes:
> The performance bottleneck in LWLockRelease()method goes through an array
> one by one to see which lock was released with O(N). As soon as the lock is
> found it performs an array to remove the lock.
Typically, such locks are released in LIFO order. Do you have any
actual evidence of a performance problem here?
regards, tom lane
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: LwLockRelease performance
@ 2021-12-02 23:50 Andres Freund <andres@anarazel.de>
parent: Ashkil Dighin <ashkildighin76@gmail.com>
1 sibling, 0 replies; 3+ messages in thread
From: Andres Freund @ 2021-12-02 23:50 UTC (permalink / raw)
To: Ashkil Dighin <ashkildighin76@gmail.com>; +Cc: pgsql-performance@lists.postgresql.org
Hi,
On 2021-12-01 19:56:11 +0530, Ashkil Dighin wrote:
> The performance bottleneck in LWLockRelease()method goes through an array
> one by one to see which lock was released with O(N). As soon as the lock is
> found it performs an array to remove the lock.
> As linear search and compaction delays the release of the lock forcing the
> other Postgres instances WAiting for the lock to be released
> Is any possible solution like
> 1. LWLockRelease() releases the lock first and then remove held lock from
> the array
You currently can't really - we don't know the to-be-released lockmode without
the lookup in the array. You could try to reason it based on the current state
of the lock, but that doesn't strike me as a great idea either.
> 2. Binary search (like non-linear structure) to reduce on high searching
> and remove all held locks
That'd likely lead to considerably worse performance. Due to the unpredictable
branches binary search is worse than linear search at low-ish array values
(obviously depends on the cost of a comparison etc).
Do you have a workload where this is a significant issue? Most of the time we
do not hold enough lwlocks for it to be a problem. I've seen it become a
bottleneck during my AIO work (*) - but IIRC I worked around it.
IIRC I observed the shifting of the locks to be the bigger issue than the
search for the locks themselves. It might be worth experimenting with not
shifting allt he subsequent locks, but instead just swapping in the
currently-last lock.
Greetings,
Andres Freund
(*) IIRC the issue is when writing back we try to write back multiple buffers
at once (using conditional lock acquisition to avoid deadlocks). Those then
are likely released in FIFO order. I think it's now not a problem anymore
because I ended up introducing the concept of locks that are owned by the AIO
subsystem for other reasons.
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2021-12-02 23:50 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-12-01 14:26 LwLockRelease performance Ashkil Dighin <ashkildighin76@gmail.com>
2021-12-02 22:19 ` Tom Lane <tgl@sss.pgh.pa.us>
2021-12-02 23:50 ` Andres Freund <andres@anarazel.de>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox