Quality and Performance
От | Simon Riggs |
---|---|
Тема | Quality and Performance |
Дата | |
Msg-id | 1196184769.4246.1072.camel@ebony.site обсуждение исходный текст |
Ответы |
Re: Quality and Performance
(Andrew Sullivan <ajs@crankycanuck.ca>)
Re: Quality and Performance ("Joshua D. Drake" <jd@commandprompt.com>) Re: Quality and Performance (Andrew Dunstan <andrew@dunslane.net>) |
Список | pgsql-hackers |
Every release we seem to have the same debates about performance issues. In 8.0 we shipped knowing that bgwriter had serious deficiencies, plus had no way of logging SQL statements for performance tuning. In 8.2 we even ended up tweaking the planner *after* release. What I don't understand is all the words about quality, yet we don't seem to include performance as part of that. Performance always seems to be a "feature" that can be left until the next release and it's never the right time to fix it. I would hope to persuade all that Performance is an integral part of Quality, not a hindrance to it. I've never worked on a software project where either the Users or the Sponsors said "don't worry about performance, it can wait, but I really love the way you coded that". Quality is very, very high with Postgres, but we also need to include performance as one of the Top Level concerns *and* do that without dropping the ball on other concerns. That clearly takes time and effort to balance those concerns. We obviously need a performance build farm and I think everyone accepts that. We just need to do it, so that's a given and is something I hope to be involved in. What I would really like to persuade everybody is that performance needs specific attention. Once we've finished integrating the code, we're in Beta and changes seem to be more difficult then. We must give time and attention both to measuring performance and to fixing the things we find. Sure we've done a lot of that, and I've been very happy with that, but recent events make me think we have lapsed back into thinking that performance is a threat to quality. I'd love to hear people say loud and clear that performance matters and we can't ship when we know about fixable performance holes. Please can we clear some space in the next release schedule for performance, plus give some credence to the thought that performance issues rate our attention just as much as other kinds of bugs? Maybe we should give each Beta a name, such as "Initial Beta", "Performance Beta", "Usability Beta" as a way of encouraging folk to focus onto particular aspects of quality at what we consider to be appropriate times to do so. Not sure whether thats a good idea, but I'd love to hear about ways to include performance as one of the essential behaviours of PostgreSQL. Your thoughts are welcome, -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
В списке pgsql-hackers по дате отправления: