Re: Review: Revise parallel pg_restore's scheduling heuristic

Tom Lane <tgl@sss.pgh.pa.us> wrote: 
> I think we've pretty much established that it doesn't make things
> *worse*, so I'm sort of inclined to go ahead and apply it.  The
> theoretical advantage of eliminating O(N^2) search behavior seems
> like reason enough, even if it takes a ridiculous number of tables
> for that to become significant.
Agreed, although I'm having some concerns about whether this should
proceed based exclusively on my benchmarks.  On a thread on the
performance list, people are talking about restores which go several
times faster with parallel restore (compared to a single job).  On my
hardware, I haven't even gotten it to run twice as fast.  This means
that parallel restore is not a good fit for servers like we have, at
least with databases like we have, which means it's probably a poor
environment to get benchmarks for this patch.  :-(
Can we get someone who has benchmarks showing parallel restore to be
eight times the speed of a single job to benchmark with this patch,
just for confirmation?
-Kevin