Re: CF3+4 (was Re: Parallel query execution)

On Sun, Jan 20, 2013 at 2:39 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> (Without meaning to paraphrase you in any negative way...)
>
> Judgements made in a few minutes are very frequently wrong, and it
> takes a lot of time to convince the person making snap decisions that
> they should revise their thinking in light of new or correct
> information. I feel we are very prone to making judgements on little
> information. This is especially true with regard to voting, with
> people zooming in from the side without having even read a patch to
> vote one way or the other, voting for the person not the idea.
>
> It can be a big problem telling the difference between a patch
> submitter that really is in possession of information that should be
> heeded and someone so blinded by their patch/idea that they mistakenly
> push forwards. At times, I have been both and I've also witnessed both
> as committer.
>
> There is a clear and understandable conservatism in being a
> reviewer/committer that people that haven't done it don't understand.
> I definitely didn't until I was a committer and I remember clearly me
> pushing for HS to go into 8.4 when it was a long way from being ready.
> I think it would be useful to expand the pool of committers and
> perhaps that can be done via some intermediate stage, though I do
> worry that the sense of responsibility might not be as strong in the
> intermediate rank ($NAME).
>
> I don't think we should be encouraging people to make fast decisions.
> Senior or not. (Though we must make decisions and have some coming
> soon).
>
> This is high in my mind right now since I've been looking at skip
> checkpoint patch for months, seeing how I feel about it. Nervous,
> basically.
>
> From that I think that some areas of the code are more critical than
> others and harder to fix in production if they go wrong. We need to be
> taking more care in critical areas and it would be useful to be able
> to mark a patch for its level of risk, rather than just "is it ready".
> That way we can gauge the risk/benefit. Examples of high risk would be
> checksums, examples of low risk would be logical replication patches.
>
> Anyway, some thoughts to discuss in May.

I agree with some but not all of your observations here, but they're
along a different line than the point I was trying to make.  I would
distinguish between value judgements (i.e. this patch is bad because
we don't want that) and architectural judgments (i.e. this patch is
bad because the logic you've added needs to go in the planner, not the
parser).  I often disagree with the value judgements that others make,
regardless of how much or little time they've spent on them, because,
well, at the end of the day, it's an opinion.  Our experiences inform
our opinions, and since we all have different experiences, we won't
always have the same opinions about everything.

Architectural judgements are something else again.  If Tom says that a
particular piece of logic needs to live in the planner rather than the
parser, the chances that he is right are upwards of 90%, in my
experience.  There are more complicated or controversial cases, of
course, but I find it's often not difficult to answer the question
"assuming we were going to do this, how ought we to do it?".  People
don't always like hearing those answers, and they're not *always*
easy, but there are many cases where I think they are.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company