On Thu, Apr 21, 2016 at 6:38 AM, Ants Aasma <ants.aasma@eesti.ee> wrote: > > On Tue, Apr 19, 2016 at 6:11 PM, Kevin Grittner <kgrittn@gmail.com> wrote: > > On Tue, Apr 19, 2016 at 9:57 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: > >> On Sun, Apr 17, 2016 at 2:26 AM, Andres Freund <andres@anarazel.de> wrote: > >>> > >>> FWIW, I could be kinda convinced that it's temporarily ok, if there'd be > >>> a clear proposal on the table how to solve the scalability issue around > >>> MaintainOldSnapshotTimeMapping(). > >> > >> It seems that for read-only workloads, MaintainOldSnapshotTimeMapping() > >> takes EXCLUSIVE LWLock which seems to be a probable reason for a performance > >> regression. Now, here the question is do we need to acquire that lock if > >> xmin is not changed since the last time value of > >> oldSnapshotControl->latest_xmin is updated or xmin is lesser than equal to > >> oldSnapshotControl->latest_xmin? > >> If we don't need it for above cases, I think it can address the performance > >> regression to a good degree for read-only workloads when the feature is > >> enabled. > > > > Thanks, Amit -- I think something along those lines is the right > > solution to the scaling issues when the feature is enabled. For > > now I'm focusing on the back-patching issues and the performance > > regression when the feature is disabled, but I'll shift focus to > > this once the "killer" issues are in hand. > > I had an idea I wanted to test out. The gist of it is to effectively > have the last slot of timestamp to xid map stored in the latest_xmin > field and only update the mapping when slot boundaries are crossed. > See attached WIP patch for details. This way the exclusive lock only > needs to be acquired once per minute. >
Why at all do we need to acquire Exclusive lock if xmin is not changing at all? Also, I think your proposed patch can effect the update of xid's for existing mappings. In particular, I am talking about below code:
