On Mon, Aug 03, 2009 at 11:21:43AM -0400, Tom Lane wrote: > "Kevin Grittner" <kevin.gritt...@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.
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 da...@sonic.net 510 536 1443 510 282 0869 If simplicity worked, the world would be overrun with insects. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers