Re: [HACKERS] When is 7.0 going Beta?

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Other than WAL, what else is half-completed and installed?

WAL is probably the thing that forces our hand here.  Vadim would know
better than anyone else whether the current state of the code is
releasable, but I bet he'll say "no".

However, I've got a couple of nontrivial concerns:

1. Table locking and shared-cache-invalidation (SI) handling.  We've
made some fundamental changes in this area since 6.5, but I don't think
we're done yet.  I know Hiroshi is very worried about this area, and
I'm not happy with it either.  And this is the kind of thing we cannot
expect to validate with a short beta test cycle.  I won't be happy until
I am logically convinced that the code is right, *and* we see solid
behavior in heavy beta testing.

2. Optimizer's handling of order-by cases, specifically whether to use
an index scan or an explicit sort.  The current code is (finally!) able
to use an index scan in all the cases where one is applicable ... but it
is *too* eager to do so, because the cost model is underestimating the
cost of an index scan.  If we don't fix that I think we will see
substantial performance degradation in some real-world cases, compared
to 6.5 which avoided some losing index scans simply because it was too
stupid to consider them.  In particular, we really need some
consideration of the effects of LIMIT in there, because that has a huge
impact on the desirability of index scan vs. sort.

3. Alpha (and other platforms) porting problems.  We're still hanging
fire on the issue of what to do about these.  If we don't do the fmgr
rewrite the way I want, I think we have to put in the Alpha patches that
Uncle George did...  and I'd rather we didn't hack up the code that
way...

> The more items in a release, the longer the beta cycle.  If you wait too
> long, you are fixing code you wrote 6 months ago, and that makes it very
> hard.  Smaller releases where the code is relatively fresh and the
> additional features minimal are cleaner, faster betas.

This is true, but it's also very hard to accomplish really large changes
that way.  Some of the things we're trying to get done in this release
are pretty pervasive changes.  I think every so often you need a slow-
birthing release where you take time to tackle big things.  I don't want
to make a habit of slow releases either, but I see plenty of reasons to
take our time with this one.
        regards, tom lane