Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <

On Thu, Apr 14, 2016 at 12:23 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:

> On 2016-04-13 16:05:25 -0500, Kevin Grittner wrote:
> > OK, thanks. I can't think of anything else to ask for at this
> > point. If you feel that you have enough to press for some
> > particular course of action, go for it.
>
> I think we, at the very least, need a clear proposal how to resolve the
> scalability issue around OldSnapshotTimeMapLock in 9.6. Personally I
> think we shouldn't release with such a large regression due to a
> performance oriented feature; but if we do, we need to be confident that
> we can easily resolve it for 9.7. In contrast to the spinlock issue I
> don't see an easy way unfortunately. Without such a plan it seems too
> likely to go unfixed for a long time otherwise.
>
>
> > Personally, I want to do some more investigation on those big
> > machines.
>
> Sounds good, especially around the regression with the feature disabled.
>

I've also run read-only test on 4x18 Intel machine between master and
snapshot_too_old reverted. In particular, I've reverted following commits:
8b65cf4c5edabdcae45ceaef7b9ac236879aae50
848ef42bb8c7909c9d7baa38178d4a209906e7c1
80647bf65a03e232c995c0826ef394dad8d685fe
a6f6b78196a701702ec4ff6df56c346bdcf9abd2
2201d801b03c2d1b0bce4d6580b718dc34d38b3e

I've obtained following results.

clients master sto-reverted
1 13918 12997
2 26143 26728
4 50521 52539
8 104330 103785
10 129067 132606
20 255561 255844
30 368472 371359
40 444486 450429
50 489950 497705
60 563606 564385
70 710579 718860
80 916480 934170
90 1089917 1152961
100 1201337 1240055
110 1147208 1207727
120 1116256 1167681
130 1066475 1120891
140 1040379 1085904
150 974064 1022160
160 938396 976487
170 953636 978120
180 920772 953843

We can see small but certain regression after snapshot too old feature.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company