From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Avoid LWLockWaitForVar() for currently held WAL insertion lock in WaitXLogInsertionsToFinish() |
Date: | 2022-11-24 18:46:19 |
Message-ID: | 20221124184619.xit4sfi52bcz2tva@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2022-11-24 18:13:10 +0530, Bharath Rupireddy wrote:
> With that said, here's a small improvement I can think of, that is, to
> avoid calling LWLockWaitForVar() for the WAL insertion lock the caller
> of WaitXLogInsertionsToFinish() currently holds. Since
> LWLockWaitForVar() does a bunch of things - holds interrupts, does
> atomic reads, acquires and releases wait list lock and so on, avoiding
> it may be a good idea IMO.
That doesn't seem like a big win. We're still going to call LWLockWaitForVar()
for all the other locks.
I think we could improve this code more significantly by avoiding the call to
LWLockWaitForVar() for all locks that aren't acquired or don't have a
conflicting insertingAt, that'd require just a bit more work to handle systems
without tear-free 64bit writes/reads.
The easiest way would probably be to just make insertingAt a 64bit atomic,
that transparently does the required work to make even non-atomic read/writes
tear free. Then we could trivially avoid the spinlock in
LWLockConflictsWithVar(), LWLockReleaseClearVar() and with just a bit more
work add a fastpath to LWLockUpdateVar(). We don't need to acquire the wait
list lock if there aren't any waiters.
I'd bet that start to have visible effects in a workload with many small
records.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2022-11-24 19:07:43 | Re: TAP output format in pg_regress |
Previous Message | Alvaro Herrera | 2022-11-24 18:23:59 | Re: Fix for visibility check on 14.5 fails on tpcc with high concurrency |