On 2016-05-03 20:57:13 +0200, Tomas Vondra wrote: > On 05/03/2016 07:41 PM, Andres Freund wrote: > >On 2016-05-03 11:46:23 -0500, Kevin Grittner wrote: > >>>was immediately addressed by another round of benchmarks after you > >>>pointed it out. > >> > >>Which showed a 4% maximum hit before moving the test for whether it > >>was "off" inline. > > > >>(I'm not clear from the posted results whether that was before or > >>after skipping the spinlock when the feature was off.) > > > >They're from after the spinlock issue was resolved. Before that the > >issue was a lot worse (see mail linked two messages upthread). > > > > > >I'm pretty sure that I said that somewhere else at least once: But to > >be absolutely clear, I'm *not* really concerned with the performance > >with the feature turned off. I'm concerned about the performance with > >it turned on. > > If you tell me how to best test it, I do have a 4-socket server sitting idly > in the corner (well, a corner reachable by SSH). I can get us some numbers, > but I haven't been following the snapshot_too_old so I'll need some guidance > on what to test.
I think it'd be cool if you could test the effect of the feature in read-only (and additionally read-mostly?) workload with various client counts and snapshot_too_old values. For the latter maybe -1, 0, 10, 60 or such? I've done so (accidentally comparing 0 and 1 instead of -1 and 1) on a two socket machine in: www.postgresql.org/message-id/20160413171955.i53me46fqqhdl...@alap3.anarazel.de It'd be very interesting to see how big the penalty is on a bigger box. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers