From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Review: Revise parallel pg_restore's scheduling heuristic |
Date: | 2009-08-03 15:21:43 |
Message-ID: | 17267.1249312903@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2009-08-03 15:22:23 | Re: CommitFest Status Summary - 2009-08-03 |
Previous Message | David Fetter | 2009-08-03 15:17:24 | Re: Alpha releases: How to tag |