Andres Freund wrote: > On 2016-05-04 00:01:20 +0300, Ants Aasma wrote: > > On Tue, May 3, 2016 at 9:57 PM, Tomas Vondra > > <tomas.von...@2ndquadrant.com> wrote: > > > 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 worry about two contention points with the current implementation. > > > > The main one is the locking within MaintainOldSnapshotTimeMapping() > > that gets called every time a snapshot is taken. AFAICS this should > > show up by setting old_snapshot_threshold to any positive value and > > then running a simple within shared buffers scale factor read only > > pgbench at high concurrency (number of CPUs or a small multiple). On a > > single socket system this does not show up. > > On a two socket system it does, check the bottom of: > http://archives.postgresql.org/message-id/20160413171955.i53me46fqqhdlztq%40alap3.anarazel.de > Note that this (accidentally) compares thresholds 0 and 10 (instead of > -1 and 10),
In other words, we expect that when the feature is disabled, no performance degradation occurs, because that function is not called at all. Honestly, I don't see any strong ground in which to base a revert threat for this feature. It doesn't scale as well as we would like in the case where a high-level is fully stressed with a read-only load -- okay. But that's unlikely to be a case where this feature is put to work. So I think accepting the promise that this feature would be improved in a future release to better support that case is good enough. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
