Horton

Re: SSI non-serializable UPDATE performance

Simon Riggs <simon@2ndquadrant.com>

View thread
From: Simon Riggs <simon@2ndQuadrant.com>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: Dan Ports <drkp@csail.mit.edu>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-04-28T07:43:30Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add fast paths for cases when no serializable transactions are running.

On Wed, Apr 27, 2011 at 7:15 PM, Kevin Grittner
<Kevin.Grittner@wicourts.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                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services