Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Ants Aasma <ants(dot)aasma(at)eesti(dot)ee>
Cc: Kevin Grittner <kgrittn(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Noah Misch <noah(at)leadboat(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Kevin Grittner <kgrittn(at)postgresql(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "pgsql-committers(at)postgresql(dot)org" <pgsql-committers(at)postgresql(dot)org>
Subject: Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Date: 2016-04-22 13:21:55
Message-ID: CAA4eK1Lu_x4ytKDQ=U7gjg3n08oONipEYmiu9SS2fy5mP6RMRQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Thu, Apr 21, 2016 at 6:38 AM, Ants Aasma <ants(dot)aasma(at)eesti(dot)ee> wrote:
>
> On Tue, Apr 19, 2016 at 6:11 PM, Kevin Grittner <kgrittn(at)gmail(dot)com> wrote:
> > On Tue, Apr 19, 2016 at 9:57 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:
> >> On Sun, Apr 17, 2016 at 2:26 AM, Andres Freund <andres(at)anarazel(dot)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:

else if (ts <= (oldSnapshotControl->head_timestamp
+((oldSnapshotControl->count_used - 1)* USECS_PER_MINUTE)))

{

/* existing mapping; advance xid if possible */

After your patch, it might skip the update to existing mappings which
doesn't seem to be a good thing.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2016-04-22 15:54:48 pgsql: Convert contrib/seg's bool-returning SQL functions to V1 call co
Previous Message Amit Kapila 2016-04-22 13:12:56 Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-04-22 13:33:23 Re: max_parallel_degree > 0 for 9.6 beta
Previous Message Asif Naeem 2016-04-22 13:14:03 Re: Truncating/vacuuming relations on full tablespaces