On Tue, Apr 19, 2016 at 8:44 PM, Robert Haas <robertmh...@gmail.com> wrote: > > On Tue, Apr 19, 2016 at 11:11 AM, Kevin Grittner <kgri...@gmail.com> wrote: > > On Tue, Apr 19, 2016 at 9:57 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > > >> 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. > > Maybe Amit could try his idea in parallel. >
Okay, will look into it. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
