Re: SSI patch version 14 - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: SSI patch version 14
Date
Msg-id 4D511794020000250003A623@gw.wicourts.gov
Whole thread Raw
In response to Re: SSI patch version 14  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: SSI patch version 14  (Dan Ports <drkp@csail.mit.edu>)
Re: SSI patch version 14  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List 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


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql
Next
From: Heikki Linnakangas
Date:
Subject: Re: SSI patch version 14