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
|
Список | 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 по дате отправления: