Re: Overhead cost of Serializable Snapshot Isolation

On Wed, Oct 12, 2011 at 8:50 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On tis, 2011-10-11 at 21:50 +0100, Simon Riggs wrote:
>> I'm keen to ensure people enjoy the possibility of upgrading to the
>> latest release. The continual need to retest applications mean that
>> very few users upgrade quickly or with anywhere near the frequency
>> with which we put out new releases. What is the point of rushing out
>> software that nobody can use? pg_upgrade doesn't change your
>> applications, so there isn't a fast path to upgrade in the way you
>> seem to think.
>
> This is a valid concern, which I share, but I think adding a few
> configuration parameters of the nature, "this setting really means what
> this setting meant in the old release" is only the tip of the iceberg.
> Ensuring full compatibility between major releases would require an
> extraordinary amount of effort, including a regression test suite that
> would be orders of magnitude larger than what we currently have.  I
> frankly don't see the resources to do that.
>
> The workaround strategy is that we maintain backbranches, so that users
> are not forced to upgrade to incompatible releases.
>
> Actually, I'm currently personally more concerned about the breakage we
> introduce in minor releases.  We'd need to solve that problem before we
> can even begin to think about dealing with the major release issue.

Thanks, these look like reasonable discussion points with no personal
comments added.

I agree that config parameters don't solve the whole problem, though
much of the iceberg is already covered with them. Currently about half
of our parameters are either on/off behaviour switches. Right now we
are inconsistent about whether we add a parameter for major features:
sync_scans, hot_standby, partial vacuum all had ways of disabling them
if required - virtually all features can be disabled, bgwriter,
autovacuum etc even though it is almost never a recommendation to do
so. I can't see a good argument for including some switches, but not
others. SSI is a complex new feature and really should have an off
switch.

Right now, we've had one report and a benchmark that show severe
performance degradation and that might have benefited from turning it
off. That is not sufficient at this point to convince some people, so
I am happy to wait to see if further reports emerge. SSI doesn't
affect everybody.

Yes, I agree that the only really good answer in the general case is
to maintain back branches, or provide enhanced versions as some
vendors choose to do. That is not my first thought, and try quite hard
to put my (/our) best work into mainline Postgres.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services