Re: reducing the overhead of frequent table locks - now, with WIP patch - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: reducing the overhead of frequent table locks - now, with WIP patch
Date
Msg-id 5087AF68-B165-41B9-AC68-D02338E7F248@nasby.net
Whole thread Raw
In response to Re: reducing the overhead of frequent table locks - now, with WIP patch  (Stephen Frost <sfrost@snowman.net>)
Responses Re: reducing the overhead of frequent table locks - now, with WIP patch
List pgsql-hackers
On Jun 7, 2011, at 8:24 AM, Stephen Frost wrote:
> * Alvaro Herrera (alvherre@commandprompt.com) wrote:
>> I note that if 2nd Quadrant is interested in having a game-changing
>> platform without having to wait a full year for 9.2, they can obviously
>> distribute a modified version of Postgres that integrates Robert's
>> patch.
>
> Having thought about this, I've got to agree with Alvaro on this one.
> The people who need this patch are likely to pull it down and patch it
> in and use it, regardless of if it's in a release or not.  My money is
> that Treat's already got it running on some massive prod system that he
> supports ( ;) ).
>
> If we get it into the first CF of 9.2 then people are going to be even
> more likely to pull it down and back-patch it into 9.1.  As soon as we
> wrap up CF1 and put out our first alpha, the performance testers will
> have something to point at and say "look!  PG scales *even better* now!"
> and they're not going to particularly care that it's an alpha and the
> blog-o-sphere isn't going to either, especially if we can say "and it'll
> be in the next release which is scheduled for May".

From the Thinking Outside The Box dept.:

Also, if the performance gains prove to be as earth-shattering as initial results indicate, there's nothing that says
we*have* to wait until the middle of next year to get this out. We could push to get 9.2 out with fewer other features,
orpossibly even break with tradition and backport this to 9.1 (or perhaps have a fork of 9.1 that we only support until
9.2is out). 

Obviously, those options all involve serious time commitments and the community will have to weigh those carefully. And
we'dhave to have very strong evidence of the benefits before even having that discussion, because the discussion itself
willlikely be resource intensive. But the option *is* there, should we decide to pursue it. 

This means that "this patch is too important to wait another 12 months" isn't really a valid point: it only has to wait
12months if thats what the community thinks is best; otherwise it could miss 9.1 *and* be out significantly before 12
monthsfrom now. 
--
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net




pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: reindex creates predicate lock on index root
Next
From: Tom Lane
Date:
Subject: Re: reindex creates predicate lock on index root