Re: Review: Revise parallel pg_restore's scheduling heuristic

> That's about 0.52% slower with the patch. Because there was over 10%
> variation in the numbers with the patch, I tried leaving out the four
> highest outliers on both, in case it was the result of some other
> activity on the system (even though this machine should have been
> pretty quiet over the weekend) and the difference fell to 0.09%.
>
> I don't know if this difference is enough to worry about; it might
> depend on whether we're comparing to the unpatched version or the
> previous patch. If it comes to choosing between a 1% to 2%
> performance gain for a "normal" case versus elimination of O(N^2)
> behavior for a worst-case scenario, I'm not sure which should win --
> especially in the absence of benchmarks showing the pessimal case.
> What would be the most productive focus for benchmarks at this point?
> The artificial pessimal case?
>
>
>

My instinct says that the variation is probably just noise, of no great
significance. I'm personally not terribly worried about the O(n^2) case,
but I think the patch is probably useful anyway, as a basis for other
people to try to improve the item selection algorithm further.

cheers

andrew