Re: Please release (was Re: nodeAgg perf tweak) - Mailing list pgsql-hackers

From
Subject Re: Please release (was Re: nodeAgg perf tweak)
Date
Msg-id 28292295$110192388441ae062c51fc68.94817314@config20.schlund.de
Whole thread Raw
Responses Re: Please release (was Re: nodeAgg perf tweak)
List pgsql-hackers
Alvaro Herrera <alvherre@dcc.uchile.cl> wrote on 01.12.2004, 15:08:11:
> On Wed, Dec 01, 2004 at 10:03:40AM +0000, Simon Riggs wrote:
>
> > Please shave 20% off everybody's aggregation queries, ugly or not.
> > You'll see a lot of happy people.
>
> When would the experimentation end, and 8.0 be finally released?
> There's real development waiting only for release to happen ...

Yes, I agree, there is real development waiting to happen. Users of
PostgreSQL are waiting to use the new software. Which is why I'd like
to see a 20% gain in aggregation performance happen. That's a huge
gain, not just the little 1 percents we keep clawing at.

For most of the people I work with, database performance is very
important. I regard performance testing as an essential part of the
release process of any performance critical software. Most earlier beta
releases were fixing functional problems and now the focus has moved to
performance related issues. Many people have trial-ported their
software to r8.0 now that it works sufficiently well to do this and are
now reporting performance issues. Also, many pure performance tests are
being run on the various betas. I can only speak for myself, but I've
spent a good deal of the last month trying to analyse performance
issues, report or document them - though others have IMHO done much
more than myself towards that goal. For me, performance is a function
that requires testing too, and bug fixes for it should be allowed into
the tail of the release. Where do you stop? When the further gains from
doing so are small....+20% tells me that point hasn't yet been reached.

Moving between releases is a big pain for people, so many would tend to
upgrade every other release. It will be some time before 8.0 makes it
into other distributions. When it does, it would be best if it is as
good as it can be. 8.1 is only a year away means it is light-years
away.

We've just gained what looks like 20%+ performance gain on the DBT-2
benchmark; with this perf tweak, we could see 20%+ performance gain on
the DBT-3 benchmark also.

I'd say if you asked most people whether we should wait another month,
but if they did, they'd get a 20% boost on some of their worst queries,
then they would choose to wait. 2% => don't bother; 20% => wait.

> I have submitted three patches already that are pending for 8.1, and the
> code keeps drifting.  There has to be a release soon.  We can't keep in
> beta forever.

Code drift is a real pain and you and I were both tortured by this
during June and July.... but I think we should stay in beta until we're
done.

> Also, I think we should consider using a time-based release process
> instead of the unpredictable mess that it is used now.  If hard
> development was done in branches and only merged when stable, we could
> do this.  (This is also something that a better SCM could help us do,
> though GCC is living proof that it can be done with CVS too.)

PostgreSQL development seems very fast to me, which is good. Timeboxing
it would do little to improve the situation for prospective users of
the software, whether or not it helps developers.

I've no comment on the SCM design - I'll follow whatever is in place.

Best Regards

Simon Riggs


pgsql-hackers by date:

Previous
From: Brett Schwarz
Date:
Subject: Re: Error handling in plperl and pltcl
Next
From: Bruce Momjian
Date:
Subject: Re: Increasing the length of