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

Поиск
Список
Период
Сортировка
От Gavin Flower
Тема Re: CF3+4 (was Re: Parallel query execution)
Дата
Msg-id 50FEC7AE.6050003@archidevsys.co.nz
обсуждение исходный текст
Ответ на Re: CF3+4 (was Re: Parallel query execution)  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Список pgsql-hackers
<div class="moz-cite-prefix">On 22/01/13 22:35, Dimitri Fontaine wrote:<br /></div><blockquote
cite="mid:m2sj5tmufc.fsf@2ndQuadrant.fr"type="cite"><pre wrap="">Tom Lane <a class="moz-txt-link-rfc2396E"
href="mailto:tgl@sss.pgh.pa.us"><tgl@sss.pgh.pa.us></a>writes: 
</pre><blockquote type="cite"><pre wrap="">In this connection I refer you to Sturgeon's Law(*): 90% of everything
is crud.  Applied to our problem, it says that 90% of all patch ideas
are bad.  Therefore, we should be expecting to reject a large fraction
of submitted patches.  It distresses me that people seem to think the
default result for a submitted patch is that it gets committed.  That's
backwards.
</pre></blockquote><pre wrap="">
+1

I still think it takes loads of stupid ideas and discussion before
reaching a point where a patch can be brewed and proposed. Once you
reach a certain point though, typically when we begin talking about
careful implementation details, then my feeling is that a patch is
necessary for the discussion to remain a productive use of everyone's
time.

So the goal in your proposed terms would be to only spend time cooking a
patch for about 10% of your ideas, and be prepared to rewrite it from
about scratch a least a couple of times (for a simple enough patch).

That matches my experience.
</pre><blockquote type="cite"><pre wrap="">For a very long time we've tried to encourage people to submit rough
ideas to pgsql-hackers for discussion *before* they start coding.
The point of that is to weed out, or fix if possible, (some of) the bad
ideas before a lot of effort has gotten expended on them.  It seems
though that less and less of that is actually happening, so I wonder
whether the commitfest process is encouraging inefficiency by making
people think they should start a discussion with a mostly-complete
patch.  Or maybe CF review is just crowding out any serious discussion
of rough ideas.  There was some discussion at the last dev meeting of
creating a "design review" process within commitfests, but nothing got
done about it ...
</pre></blockquote><pre wrap="">
I share that feeling that while commit fest is a giant step forward as
far as allowing patches to make progress and hit the next release
without delaying said release, it might be encouraging people to cook
patches too early: there's no entry for "crazy ideas" or design.

I guess in getting more formal it's harder for newcomers to just throw
(not so) random ideas on list, as it used to be the only way to begin a
contribution to PostgreSQL.

My understanding is that we already have too many lists, but maybe we
could have another one to just speak about those 10% ideas that turn
into patches or commit fest entries (pgsql-workers) and keep hackers for
crazy idea, design, community processes, etc. I'm not sold on it myself,
but it could maybe help in encouraging design ideas again?

Regards,
</pre></blockquote><font size="-1">Maybe we should have a list named 'cra<font size="-1">zy talk' for such ideas.<br
/><br/><font size="-1">Possibly encourage Tom <font size="-1">and other pg heavy weights to write brief notes about
theirinten<font size="-1">tions<font size="-1">.  So people ca<font size="-1">n</font> see that even the best pg
developerscan have half baked ideas, to encourage <font size="-1">newcomers</font> and less experienced developers to
letpeople know well in advance what their intentions are.<br /><br /><font size="-1">Most people don't realize tat to
bereally stupid, one needs to be both hi<font size="-1">ghly intelligent and creative!<br /><br /><font size="-1">More
tothe poin<font size="-1">t</font>, perhaps, is that the most effective developers often have many silly ideas that
are:well intentioned but not practicable<font size="-1">,</font> ini<font size="-1">tially implemented
poorly,</font></font></font></font></font></font></font></font></font></font><fontsize="-1"><font size="-1"><font
size="-1"><fontsize="-1"><font size="-1"><font size="-1"><font size="-1"><font size="-1"><font size="-1"><font
size="-1"><fontsize="-1"><font size="-1"><font size="-1"><font size="-1"><font size="-1"><font size="-1"><font
size="-1"><fontsize="-1"><font size="-1"> or develop something that seem good until grim reality hits.  However, when
theystrike gold, the<font size="-1">y improve pg: in considerable ways, make trivial changes that are disp<font
size="-1">r</font>oportionately
useful,</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font><font
size="-1"><fontsize="-1"><font size="-1"><font size="-1"><font size="-1"><font size="-1"><font size="-1"><font
size="-1"><fontsize="-1"><font size="-1"><font size="-1"><font size="-1"><font size="-1"><font size="-1"><font
size="-1"><fontsize="-1"><font size="-1"><font size="-1"><font size="-1"><font size="-1"><font size="-1"><font
size="-1"><fontsize="-1"><font size="-1"><font size="-1"><font size="-1"><font size="-1"><font size="-1"><font
size="-1"><fontsize="-1"><font size="-1"><font size="-1"><font size="-1"><font size="-1"><font size="-1"><font
size="-1"><fontsize="-1"><font size="-1"><font size="-1"><font size="-1"> or put a lot of <font size="-1">effort into
makin<fontsize="-1">g what superficially looks like a simple idea to actually work without bad side effects.<br /><br
/><fontsize="-1">I am sure with even my 40+ years of development experience in other areas, that if I attempted a
'trivial'change to pg, that I would most likely cause unwanted side effects without realizing it - assuming I got it
workingat all!  Tom and others would then quite rightly reject my patch, or give me constructive <font
size="-1">criticism(that I might take as negative feed<font size="-1">back if I was depressed!).  Howevever, if I first
proposedmy idea on a 'crazy talk' mailing list, then poss<font size="-1">i</font>bly I would either get suggestions as
tohow to proceed to avoid such side effects, or be told that <font size="-1">what I proposed was not wo<font
size="-1">r<fontsize="-1">t</font>h the effort. In the latter case, it would be up to me to re<font size="-1">search
reasonsfor proceedin<font size="-1">g, if I felt strongly tha<font size="-1">t I was
right.</font></font></font></font></font></font></font></font><br
/></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font><br
/><br/><font size="-1">Cheers,<br /><font size="-1">Gavin</font><br /></font></font></font></font></font></font></font> 

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

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Event Triggers: adding information
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Prepared statements fail after schema changes with surprising error