Quality and Performance - Mailing list pgsql-hackers

From Simon Riggs
Subject Quality and Performance
Date
Msg-id 1196184769.4246.1072.camel@ebony.site
Whole thread Raw
Responses Re: Quality and Performance
Re: Quality and Performance
Re: Quality and Performance
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: [GENERAL] Empty arrays with ARRAY[]
Next
From: "Usama Munir"
Date:
Subject: Re: String encoding during connection "handshake"