Re: Review: Revise parallel pg_restore's scheduling heuristic

On Mon, Aug 03, 2009 at 11:21:43AM -0400, Tom Lane wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> > Over the weekend I ran 40 restores of Milwaukee County's production
> > data using Friday's snapshot with and without the patch. I alternated
> > between patched and unpatched. It appears that this latest version is
> > slightly slower for our production database on the same machine and
> > configuration where the previous patch appeared to be 1% to 2% faster
> > than unpatched (although I had fewer samples of that).
>
> I think we can conclude that for this particular test case, the effects
> of the patch are pretty much masked by noise. I definitely see no way
> that the latest version of the patch could really be slower than the
> original; it has the same job-scheduling behavior and strictly less
> list-munging overhead. Now the patch could be slower than unpatched
> as a result of different job-scheduling behavior ... but there's no
> evidence here of a consistently measurable benefit or loss from that.
>
> IIRC daveg was volunteering to do some tests with his own data; maybe
> we should wait for those results.

I have run extensive tests with three trials of each configuration on two
hosts with a variety of db sizes from 3GB to 142GB. These just finished,
and I will send a more detailed summary later, but at the moment I don't
see any significant difference between the patched and vanilla pg_restore.

-dg

--
David Gould daveg(at)sonic(dot)net 510 536 1443 510 282 0869
If simplicity worked, the world would be overrun with insects.