Re: Not ready for 8.3

Поиск
Список
Период
Сортировка
От Joshua D. Drake
Тема Re: Not ready for 8.3
Дата
Msg-id 4649F59A.2090505@commandprompt.com
обсуждение исходный текст
Ответ на Re: Not ready for 8.3  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Not ready for 8.3  (Oleg Bartunov <oleg@sai.msu.su>)
Re: Not ready for 8.3  (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>)
Re: Not ready for 8.3  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
> 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 
>> 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.

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
certainlynot 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






> 



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: pg_comparator table diff/sync
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Not ready for 8.3