Skip site navigation (1) Skip section navigation (2)

Re: SSI non-serializable UPDATE performance

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Dan Ports <drkp(at)csail(dot)mit(dot)edu>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SSI non-serializable UPDATE performance
Date: 2011-04-28 07:43:30
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
On Wed, Apr 27, 2011 at 7:15 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:

> (1) If a tuple which is predicate locked, or sits on a predicate-
> locked page, is updated, the predicate lock is duplicated for the
> new tuple.  We have found patterns of updates involving four or more
> transactions where a non-serializable transaction can hide
> serialization anomalies among serializable transactions if we don't
> do this.  Someone suggested that we could take out this call and
> just document that serializable transactions may not comply with the
> standard-defined behavior when there are concurrent non-serializable
> transactions.  We were unable to show a measurable performance hit
> on this, although this was just with 32 clients hitting a 16
> processor machine.  There was at least a theoretical possibility
> that with higher levels of concurrency there could have been a new
> contention point for a LW lock here which could affect performance.
> We added a quick return which didn't need to check any locks at the
> front of this routine which is taken if there are no active
> serializable transactions on the cluster at the moment of update.

Surprised to hear nobody mentioning memory reordering issues about
that, but I'm not running Itaniums anywhere.

 Simon Riggs         
 PostgreSQL Development, 24x7 Support, Training & Services

In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2011-04-28 07:53:37
Subject: Re: SIREAD lock versus ACCESS EXCLUSIVE lock
Previous:From: Simon RiggsDate: 2011-04-28 07:40:10
Subject: Re: SSI non-serializable UPDATE performance

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group