On Thu, Apr 14, 2016 at 12:23 AM, Andres Freund <and...@anarazel.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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers