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