Re: reducing the overhead of frequent table locks - now, with WIP patch

On Wed, Jun 8, 2011 at 11:39 AM, Jim Nasby <jim(at)nasby(dot)net> wrote:
> On Jun 7, 2011, at 8:24 AM, Stephen Frost wrote:
>> * Alvaro Herrera (alvherre(at)commandprompt(dot)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, or possibly even break with tradition and backport this to 9.1 (or perhaps have a fork of 9.1 that we only support until 9.2 is out).
>
> Obviously, those options all involve serious time commitments and the community will have to weigh those carefully. And we'd have to have very strong evidence of the benefits before even having that discussion, because the discussion itself will likely 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 12 months if thats what the community thinks is best; otherwise it could miss 9.1 *and* be out significantly before 12 months from now.

Right. The community gets to decide when the community wants to
release, and with what features. Right now, the consensus is that we
want to finish up 9.1 and release it. It doesn't seem impossible that
we could manage to do that before this patch is ready for commit,
which is why I don't want to try to slip this into 9.1 no matter how
valuable it is.

I also feel that the fundamental thing we need in order to have better
releases is more developers spending more time developing cool stuff.
That is why I am somewhat dismayed to see this discussion veer off on
what I consider to be a tangent about release scheduling. It took me
about 3 days to write the patch. I've now spent the better part of a
day on this scheduling discussion. I would rather have spent that
time improving the patch. Or working on some other patch. Or getting
9.1 out the door. Now, mind you, I think release scheduling is
important. I believe in the value of good project management. But if
we make every cool patch that comes along into an opportunity to fight
about the release schedule, that's not productive. Already, I feel
that any hope I might have had of getting useful technical feedback on
this patch anytime in the near future has been basically obliterated.
What a bummer.

As for the 9.2 schedule, I'm actually hoping that 9.2 will be a big
release for performance, sorta like 8.3 was. I think that to make
that happen, we're going to need more than one good patch. This patch
can be part of that picture, but there are many users who derive no
benefit or only a small benefit from it. Of course, there are some
who will get a big benefit, and I'm as excited about that as everyone
else, but if we can broaden the aperture a bit and come up with a
variety of improvements that hit on a variety of use cases, then we'll
really have something to brag about.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company