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

Re: SSI patch version 14

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: <simon(at)2ndQuadrant(dot)com>,<markus(at)bluegap(dot)ch>, <drkp(at)csail(dot)mit(dot)edu>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SSI patch version 14
Date: 2011-02-08 16:14:44
Message-ID: 4D511794020000250003A623@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-hackers
I wrote:
 
> The multiplier of 10 PredXactList structures per connection is
> kind of arbitrary.  It affects the point at which information is
> pushed to the lossy summary, so any number from 2 up will work
> correctly; it's a matter of performance and false positive rate. 
> We might want to put that on a GUC and default it to something
> lower.
 
If the consensus is that we want to add this knob, I can code it up
today.  If we default it to something low, we can knock off a large
part of the 2MB increase in shared memory used by SSI in the default
configuration.  For those not using SERIALIZABLE transactions the
only impact is that less shared memory will be reserved for
something they're not using.  For those who try SERIALIZABLE
transactions, the smaller the number, the sooner performance will
start to drop off under load -- especially in the face of a
long-running READ WRITE transaction.  Since it determines shared
memory allocation, it would have to be a restart-required GUC.
 
I do have some concern that if this defaults to too low a number,
those who try SSI without bumping it and restarting the postmaster
will not like the performance under load very much.  SSI performance
would not be affected by a low setting under light load when there
isn't a long-running READ WRITE transaction.
 
-Kevin

In response to

Responses

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2011-02-08 16:16:43
Subject: Re: SSI patch version 14
Previous:From: Pavel StehuleDate: 2011-02-08 16:05:01
Subject: Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql

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