Re: Review: Revise parallel pg_restore's scheduling heuristic - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Review: Revise parallel pg_restore's scheduling heuristic
Date
Msg-id 4A7C3F070200002500029687@gw.wicourts.gov
Whole thread Raw
In response to Re: Review: Revise parallel pg_restore's scheduling heuristic  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Review: Revise parallel pg_restore's scheduling heuristic  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: Review: Revise parallel pg_restore's scheduling heuristic  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> wrote: 
> So should we give up on this patch?
No, this is not news; just confirmation of the earlier gut feelings
and less convincing statistics that there is no problem.  Tom's
argument that if there's no slowdown for common cases, preventing
O(N^2) behavior for extreme cases is compelling for me, and we've
beaten up on it enough for me to feel comfortable that it doesn't
break anything.
I held off on investigating the artificial extreme cases when I
thought we might possibly have a small performance problem here; but
this statistics exercise has just gotten me from "gut feel" that it
was noise and "not having 90% confident that we made things worse" to
"90% of the time noise would produce a bigger difference".  It's one
thing to require 90% confidence that an improvement is real before
accepting something, it's another to accept a change on the basis of
not having 90% confidence that there is degradation -- so I wanted to
see a more compelling statistic.
Personally, I'm happy with it being in "Ready for Committer" status. 
I remember someone else on the thread saying that besides the
elimination of O(N^2) behavior, it provided better structure for
future enhancements.
I'll run a few more benchmarks over the next few weeks to try to
characterize the improvements in extreme cases, "just for the record",
but I don't think we want to wait for that; we've got justification
enough as is.
-Kevin


pgsql-hackers by date:

Previous
From: Emmanuel Cecchet
Date:
Subject: Durability?
Next
From: Robert Haas
Date:
Subject: Re: Review: Revise parallel pg_restore's scheduling heuristic