Re: Review: Revise parallel pg_restore's scheduling heuristic
От | Tom Lane |
---|---|
Тема | Re: Review: Revise parallel pg_restore's scheduling heuristic |
Дата | |
Msg-id | 17267.1249312903@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Review: Revise parallel pg_restore's scheduling heuristic ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: Review: Revise parallel pg_restore's scheduling heuristic
Re: Review: Revise parallel pg_restore's scheduling heuristic |
Список | 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 по дате отправления: