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 по дате отправления:
Следующее
От: Tom LaneДата:
Сообщение: Re: Prepared statements fail after schema changes with surprising error