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.
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.
Leaving only those patches that have confirmed reviewers to be worked
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
Fairness and not pushing our problems out to the future --- address
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.
Life... is a perpetual problem. We do what we can, when we can, and the
best that we can.
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
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:
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?
Joshua D. Drake
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly