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

On Mon, Jun 6, 2011 at 10:49 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> My point was that we have in the past implemented performance changes
> to increase scalability at the last minute, and also that our personal
> risk perspectives are not always set in stone.
>
> Robert has highlighted the value of this change and its clearly not
> beyond our wit to include it, even if it is beyond our will to do so.

So, at the risk of totally derailing this thread -- what this boils
down to is a philosophical disagreement.

It seems to me (and, I think, to Tom and Heikki and others as well)
that it's not possible to keep on making changes to the release right
up until the last minute and then expect the release to be of high
quality. If we keep committing new features, then we'll keep
introducing new bugs. The only hope of making the bug count go down
at some point is to stop making changes that aren't bug fixes. We
could come up with some complex procedure for determining whether a
patch is important enough and non-invasive enough to bypass the normal
deadline, but that would probably lead to a lot more arguing about
procedure, and realistically, it's still going to increase the bug
count at least somewhat. IMHO, it's better to just have a deadline,
and stuff either makes it or it doesn't. I realize we haven't always
adhered to the principle in the past, but at least IMV that's not a
mistake we want to continue repeating.

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