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

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: CF3+4 (was Re: Parallel query execution)
Дата
Msg-id CA+U5nMJcVNFSrQ+rFMynDM6tCG+wiAeZJ9tqbC0hz7P5LaR_yw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: CF3+4 (was Re: Parallel query execution)  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: CF3+4 (was Re: Parallel query execution)  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: CF3+4 (was Re: Parallel query execution)  (Robert Haas <robertmhaas@gmail.com>)
Re: CF3+4 (was Re: Parallel query execution)  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-hackers
On 20 January 2013 18:42, Robert Haas <robertmhaas@gmail.com> wrote:
> On Sat, Jan 19, 2013 at 5:21 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
>> Sometime this type of high-level summary review does happen, at the senior
>> person's whim, but is not a formal part of the commit fest process.
>>
>> What I don't know is how much work it takes for one of those senior people
>> to make one of those summary judgments, compared to how much it takes for
>> them to just do an entire review from scratch.
>
> IME, making such summary judgements can often be done in a few
> minutes, but convincing that the patch submitter that you haven't
> created the objection purely as an obstacle to progress is the work of
> a lifetime.  We could perhaps do better at avoiding perverse
> incentives, there.

(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.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: proposal: fix corner use case of variadic fuctions usage
Следующее
От: Phil Sorber
Дата:
Сообщение: Re: [WIP] pg_ping utility