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

From Tom Lane
Subject Re: Review: Revise parallel pg_restore's scheduling heuristic
Date
Msg-id 17267.1249312903@sss.pgh.pa.us
Whole thread Raw
In response to Re: Review: Revise parallel pg_restore's scheduling heuristic  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: Review: Revise parallel pg_restore's scheduling heuristic  (Josh Berkus <josh@agliodbs.com>)
Re: Review: Revise parallel pg_restore's scheduling heuristic  (daveg <daveg@sonic.net>)
List pgsql-hackers
"Kevin Grittner" <Kevin.Grittner@wicourts.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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: Alpha releases: How to tag
Next
From: Tatsuo Ishii
Date:
Subject: Re: CommitFest Status Summary - 2009-08-03