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
