On 06/14/2011 01:16 PM, Robert Haas wrote:
> But there's no reason that code (which may or may not eventually prove
> useful) has to be incorporated into the main tree. We don't commit
> code so people can go benchmark it; we ask for the benchmarking to be
> done first, and then if the results are favorable, we commit the code.
>
Who said anything about this being a commit candidate? The "WIP" in the
subject says it's not intended to be. The community asks people to
submit design ideas early so that ideas around them can be explored
publicly. One of the things that needs to be explored, and that could
use some community feedback, is exactly how this should be benchmarked
in the first place. This topic--planning based on cached
percentage--keeps coming up, but hasn't gone very far as an abstract
discussion. Having a patch to test lets it turn to a concrete one.
Note that I already listed myself as the reviewer here, so it's not
even like this is asking explicitly for a community volunteer to help.
Would you like us to research this privately and then dump a giant patch
that is commit candidate quality on everyone six months from now,
without anyone else getting input to the process, or would you like the
work to happen here? I recommended Cédric not ever bother soliciting
ideas early, because I didn't want to get into this sort of debate. I
avoid sending anything here unless I already have a strong idea about
the solution, because it's hard to keep criticism at bay even with
that. He was more optimistic about working within the community
contribution guidelines and decided to send this over early instead. If
you feel this is too rough to even discuss, I'll mark it returned with
feedback and we'll go develop this ourselves.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
