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

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: reducing the overhead of frequent table locks - now, with WIP patch
Дата
Msg-id BANLkTin9HA7UydKyezoQV-3QdDfXf5w7ww@mail.gmail.com
обсуждение исходный текст
Ответ на Re: reducing the overhead of frequent table locks - now, with WIP patch  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: reducing the overhead of frequent table locks - now, with WIP patch  (Christopher Browne <cbbrowne@gmail.com>)
Список pgsql-hackers
On Mon, Jun 6, 2011 at 5:14 PM, Kevin Grittner
<Kevin.Grittner@wicourts.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Postmaster holding unlinked files for pg_largeobject table
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: Range Types and extensions