On Tue, 2005-01-18 at 23:26 -0500, Tom Lane wrote:
> Not yet --- I suggested it but didn't get any yeas or nays. I don't
> feel this is solely core's decision anyway ... what do the assembled
> hackers think?
I'm not sure it's a great idea.
I'm not aware of a recent example of short development cycles working
well in this project. That isn't to say we *can't* do one effectively,
just that history is not on our side (does anyone recall the plans to
finish off Win32 in 7.5 and get it out the door quickly?)
The primary justification I've heard for the no-initdb policy is that it
would provide a smooth upgrade path for 8.0 users if/when the ARC patent
is granted. I don't think this is the best way to deal with the ARC
issue: it seems silly to handicap an entire development cycle because of
one (potential) problem. Not to mention that it's not even certain
whether an ARC replacement will be needed: we might be able to adapt the
existing code to workaround the patent, the patent might not be granted,
or IBM might grant us a license to use it. It's also worth emphasizing
that this would be a rather severe limitation on what kind of new
developments can go into 8.1.
I think the proper fix for the ARC issue is an 8.0.x release with a new
replacement policy. To avoid introducing instability into 8.0, we should
obviously test the new buffer replacement policy *very* carefully.
However, I think the ARC replacement should *not* be a fundamental
change in behavior: the algorithm should still attempt to balance
recency and frequency, to adjust dynamically to changes in workload, to
avoid "sequential flooding", and to allow constant-time page
replacement. Ideally the ARC replacement would do something similar to
ARC but via a different means. If such a patch were developed, I don't
think it would be a herculean task to include it in an 8.0.x release
after a lot of careful testing and code review.
-Neil
