Hello!
On 2020-11-14 20:07, Alexander Korotkov wrote:
> Hmm... Let's see the big picture. You've recently committed a
> patchset, which greatly improved the performance of GetSnapshotData().
> And you're making further improvements in this direction. But you're
> getting trouble in measuring the effect, because Postgres is still
> stuck on ProcArrayLock. And in this thread you propose a workaround
> for that implemented on the pgbench side. My very dumb idea is
> following: should we finally give a chance to more fair lwlocks rather
> than inventing workarounds?
>
> As I remember, your major argument against more fair lwlocks was the
> idea that we should fix lwlocks use-cases rather than lwlock mechanism
> themselves. But can we expect that we fix all the lwlocks use-case in
> any reasonable prospect? My guess is 'no'.
>
> Links
> 1.
> https://www.postgresql.org/message-id/CAPpHfdvJhO1qutziOp%3Ddy8TO8Xb4L38BxgKG4RPa1up1Lzh_UQ%40mail.gmail.com
Sorry I'm not familiar with the internal architecture of snapshots,
locks etc. in postgres, but I wanted to ask - what exact kind of patch
for fair lwlocks do you want to offer to the community? I applied the
6-th version of the patch for fair lwlocks from [1] to the old master
branch (see commit [2]), started many threads in pgbench (-M prepared -c
1000 -j 500 -T 10 -P1 -S) and I did not receive stable first progress
reports, which IIUC are one of the advantages of the discussed patch for
the pgbench (see [3])...
[1]
https://www.postgresql.org/message-id/CAPpHfduV3v3EG7K74-9htBZz_mpE993zGz-%3D2k5RNA3tqabUAA%40mail.gmail.com
[2]
https://github.com/postgres/postgres/commit/84d514887f9ca673ae688d00f8b544e70f1ab270
[3]
https://www.postgresql.org/message-id/20200227185129.hikscyenomnlrord%40alap3.anarazel.de
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
