Robert Haas wrote: > Well, my first thought is - I'm not sure it's realistic to think > we're going to get this committed to 9.1. > > But that's not a very helpful thought. I just don't know who is > going to review 7700 lines of code in the next month, and it > doesn't sound like it can be decomposed into independent > subfeatures that can be committed independently. Splitting it up by > directory isn't really all that helpful. I hope someone will step > up to the plate; I'm pretty sure I can't do it. I hope so, too. FWIW, I submitted this patch with almost 2000 fewer lines in what I hoped was a form suitable for initial commit in the 2010-09 CF, knowing full well there were a number of optimizations and improvements I would like to get in before release. But Heikki felt that it wasn't acceptable without those changes -- and for reasons which I find totally understandable. There's sort of a Catch-22 here for large features like this -- if you submit them in skeletal form they aren't accepted because we don't want code in the official repository which isn't production quality yet. But if you flesh it out to where it is production quality, then it's large enough to be hard to review. I know this isn't the first time this issue has been brought up, but I'm feeling it keenly at the moment. There are three contributors who have already been through the code for this patch in sufficient detail to help advance it -- and I'm most grateful for what they've already done. Hopefully those who have already done that won't find it too hard to digest the patch with its latest improvements, and will have the time and inclination to give it a go. One thing that would help a lot besides code review is performance testing. I did some months ago and I know Dan booked time on MIT benchmarking systems and got good numbers, but with the refactoring it would be good to redo that, and benchmarking properly can be very time consuming. Existing benchmark software might need to be tweaked to retry transactions which fail with SQLSTATE 40001, or at least continue on with out counting those in TPS figures, since applications using this feature will generally have frameworks which automatically do retries for that SQLSTATE. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers