Re: management of large patches

Robert Haas wrote:
> - MERGE
> - checkpoint improvements
>

As far as these two go, the state of MERGE is still rougher than I would
like. The code itself isn't too hard to read, and that the errors that
are popping up tend to be caught by assertions (rather than just being
mysterious crashes) makes me feel a little better that there's some
defensive coding in there. It's still a 3648 line patch that touches
grammar, planner, and executor bits though, and I've been doing mainly
functional and coding style review so far. I'm afraid here's not too
many committers in a good position to actually consume the whole scope
of this thing for a commit level review. And the way larger patches
tend to work here, I'd be surprised to find it passes through such a
review without some as yet unidentified major beef appearing. Will see
what we can do to help move this forward more before the CF start.

The checkpoint changes I'm reworking are not really large from a code
complexity or size perspective--I estimate around 350 lines of diff,
with the rough version I submitted to CF2010-11 at 258. I suspect it
will actually be the least complicated patch to consume from that list,
from a committer perspective. The complexity there is mainly in the
performance testing. I've been gearing up infrastructure the last
couple weeks to automate and easily publish all the results I collect
there. The main part that hasn't gone through any serious testing yet,
auto-tuning the spread interval, will also be really easy to revert if a
problem is found there. With Simon and I both reviewing each others
work on this already, I hope we can keep this one from clogging the
committer critical path you're worried about here.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books