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

On Mon, Jun 6, 2011 at 5:14 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:

> Perhaps the best way to describe the suggestion that this be
> included in 9.1 isn't that it's an insane suggestion; but that it's
> a suggestion which, if adopted, would be likely to drive those who
> are striving for a more organized development and release process
> insane.

Kevin, I respect your opinion and thank you for stating your case
without insults.

In this discussion it should be recognised that I have personally
driven the development of a more organized dev and release process. I
requested and argued for stated release dates to assist resource
planning and suggested commitfests as a mechanism to reduce the
feedback times for developers. I also provided the first guide to
patch reviews we published. So I am a proponent of planning and
organization, though some would like to claim I see things
differently.

The major problems of the dev process are now solved, yet "more
organization" is still being discussed, as if "more" == "better". What
I hear is "changed organization" and I am not certain that all
"change" == "better" in what I see is a leading example of how to
produce great software.

Releasing regularly is important, but not more important than
anything. Ever. Period. Trying to force that will definitely make you
mad, I can see. I request that people stop trying to enforce a process
so strictly that sensible and important change cannot take place when
needed.

> Or one could look at it in a cost/benefit format -- major features
> delivered per year go up by holding the line, administrative costs
> are reduced, and people who are focusing on release stability get
> more months per year to do development.

I do look at it in a cost/benefit format. The problem is the above
statement has nothing user-centric about it.

The cost to us is a few days work and the benefit is a whole year's
worth of increased performance for our user base, which has a hardware
equivalent well into the millions of dollars.

And that's ignoring the users that would've switched to using Postgres
earlier, and those who might leave because of competitive comparison.

I won't say any more about this because I am in no way a beneficiary
from this and even my opinion is given unpaid.

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