On Tue, Apr 19, 2016 at 10:14 AM, 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: >>> On Sun, Apr 17, 2016 at 2:26 AM, Andres Freund <and...@anarazel.de> wrote: >>>> >>>> On 2016-04-16 16:44:52 -0400, Noah Misch wrote: >>>> > That is more controversial than the potential ~2% regression for >>>> > old_snapshot_threshold=-1. Alvaro[2] and Robert[3] are okay releasing >>>> > that way, and Andres[4] is not. >>>> >>>> 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. > > Maybe Amit could try his idea in parallel.
That would be great! -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
