Re: Not ready for 8.3

Joshua D. Drake wrote:
> > That is not fair to patch submitters, and pushes the problem to 8.4,
> > where it will be no better.
> 
> If it isn't done, it isn't done. We aren't dropping the patch. The patch 
> has been accepted, just not reviewed. It is just delayed.

Delayed isn't rejected, but it isn't accepted either.  I see that as
unfair to patch submitters, and not making things any easier.  It just
pushes our problem into 8.4.

> >> Sure it is, if we have a short release cycle. There are plenty of things 
> >> out there that are not quite ready yet, that could be if we released 
> >> again next January...
> > 
> > Huh, you didn't answer my issue about unfair.
> 
> Sure I did see above :). Unfair would be to let go all together. We are 
> just delaying. If we don't have reviewers, we don't have reviewers and 
> as I look at the open list we have more reviewers than we did for 8.2 so 
> I would suspect that 8.4 is going to go smoother as it is.

And even more patches for 8.4.

Given your list below, let me match it up with Tom's comments and see if
I can defer some patches that are not ready for application.  I think
bitmapped indexes are one of them.

---------------------------------------------------------------------------


> >> Leaving only those patches that have confirmed reviewers to be worked 
> >> through.
> >>
> >> FYI, whoever did that Todo:Patch status, Bravo! That is easily one of 
> >> the smallest but best improvements to the process I have seen in recent 
> >> memory.
> > 
> > Fairness and not pushing our problems out to the future --- address
> > those issues.
> 
> Life isn't fair. It isn't like we are telling these people to bugger 
> off. We are just delaying the review to what is a reasonable workload 
> for the current set of reviewers.

Again, it just pushed things off.  I see just keeping going as a better
approach.

> Life... is a perpetual problem. We do what we can, when we can, and the 
> best that we can.

Yea, but we have to do that best we can, not give up and hope something
improves for 8.4, because I see no basis for such a belief.

> Taking my suggestion above for leaving patches that don't have reviewers 
>   let's look at some of them.
> 
> Tsearch2 in core. I know that Tom has some reservations, he I and Treat 
> all commented on how it was done and to my knowledge those reservations 
> have not been resolved.
> 
> HOT is a huge patch that has gone round and round and round. Lots of 
> people want it, including me but it is invasive enough to where it may 
> due it good to work through another cycle.
> 
> Grouped Index Tuples. I like the result of this patch. I tested the 
> performance and it did work as advertised but we didn't get much 
> feedback as a whole from known hackers. Either there isn't much interest 
>   or we are too busy. Either way it is certainly not a critical patch 
> and can be pushed.
> 
> Concurrent psql, nifty but still trying to decide on actual interface.
> 
> Full Page Writes Improvement, doesn't actually do anything *yet* (as far 
> as I can tell) it just makes it so something can be done in the future. 
> It is also apparently a small patch.
> 
> UTF8 text matching performance improvements (todo wiki link broke), so I 
> don't have much comment.
> 
> On Disk Bitmap indexes (todo wiki link broke): Doesn't support Vacuum 
> (to my knowledge), community member tested, reported problems... no 
> response yet from author. The author is known to be time constrained, 
> boot it till 8.4.
> 
> Posix shared memory, not usable in current state per Tom's comments and 
> Apples, agreement. Dumped till 8.4 or further.
> 
> Stream bitmaps, apparently needed more info from Gavin (see previous 
> comment about author's time). No feed back since March 9th. Dumped till 8.4.
> 
> Bitmapscan change, this one is unfortunate because at the time Heikki 
> had resources and desire but was basically ignored. Sometimes we have to 
> punt although Heikki is doing patch review right now and it is not 
> unheard of for a patch reviewer to commit his own patch (in this case we 
> would need a comitter to actually accept it.).
> 
> Updateable cursors, apparently breaks explain and patch has been 
> updated. Punt!
> 
> Group Commit, Heikki has already suggested that it may be a good idea to 
> push for 8.4 on this patch: http://momjian.us/mhonarc/patches/msg00127.html
> 
> Index Advisor.. I think the link is wrong:
> 
> http://momjian.us/mhonarc/patches/msg00119.html
> 
> Ctid chain patch, apparently no discussion since last January even 
> though requests had been made to change the patch to some degree. Punt.
> I will note that no one was negative about the patch, it just doesn't 
> appear that the requests were ever finished.
> 
> Error correct for n_dead_tuples, patch was requested for hold in Feb. No 
> discussion since. Punt!
> 
> DSM, apparently includes n_dead_tuples, please remove n_dead_tuples line 
> on todo. Significant memory allocation enhancements are expected in 8.4 
> for this. Discussion died in April. Concerns were raised about how 
> memory is allocated (fixed, shared) which author already admints to 
> wanting to change for 8.4.
> 
> PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be 
> developed outside of core. Don't get me wrong I like the feature but it 
> can take advantage of facilities outside of core.
> 
> So there ya go... thoughts, flames?
> 
> Sincerely,
> 
> Joshua D. Drake
> 
> 
> 
> 
> 
> 
> > 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo@postgresql.org so that your
>        message can get through to the mailing list cleanly

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +