Re: [HACKERS] When is 7.0 going Beta?
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] When is 7.0 going Beta? |
Дата | |
Msg-id | 22015.944543404@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] When is 7.0 going Beta? (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] When is 7.0 going Beta?
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: