Re: Review: Revise parallel pg_restore's scheduling heuristic
От | Robert Haas |
---|---|
Тема | Re: Review: Revise parallel pg_restore's scheduling heuristic |
Дата | |
Msg-id | 603c8f070908071250q1e897481q40b566c983da50dc@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Review: Revise parallel pg_restore's scheduling heuristic (Sam Mason <sam@samason.me.uk>) |
Список | pgsql-hackers |
On Fri, Aug 7, 2009 at 3:36 PM, Sam Mason<sam@samason.me.uk> wrote: > On Fri, Aug 07, 2009 at 03:18:54PM -0400, Robert Haas wrote: >> On Fri, Aug 7, 2009 at 3:08 PM, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: >> > With the 20 samples from that last round of tests, the answer (rounded >> > to the nearest percent) is 60%, so "probably noise" is a good summary. >> >> So should we give up on this patch? > > That's the joy of stats, it only tells you *very* precisely about the > *exact* thing you've chosen to test. Interpreting the result is still > awkward, but it does remove one problem! > > If you think the tests that've been done cover the use cases that the > new code was been designed to help with and you're not showing any > benefit I'd probably give up and put it down to a learning experience. > Sorry, but I've not been following enough to comment on this much more. Yeah, I more wanted to here from Tom or Kevin or anyone else who had a technical thought about this. I haven't looked at the patch, but there may be reasons other than performance to commit it - or there may not. Tom posted a note on the commitfest suggesting that maybe we should give up on this, and I don't care one way or the other, except that in my role as CommitFest manager (or Mom) I'm trying to push the remaining patches to some sort of conclusion: either committed, or rejected, or needs more work please resubmit for the next CommitFest. ...Robert
В списке pgsql-hackers по дате отправления: