Re: Review: Revise parallel pg_restore's scheduling heuristic
От | Kevin Grittner |
---|---|
Тема | Re: Review: Revise parallel pg_restore's scheduling heuristic |
Дата | |
Msg-id | 4A6D875F0200002500028D83@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: Review: Revise parallel pg_restore's scheduling heuristic (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Review: Revise parallel pg_restore's scheduling heuristic
Re: Review: Revise parallel pg_restore's scheduling heuristic |
Список | pgsql-hackers |
Andrew Dunstan <andrew@dunslane.net> wrote: > To performance test this properly you might need to devise a test > that will use a sufficiently different order of queueing items to > show the difference. It would appear that I need help with devising a proper test. So far, all tests have shown no difference in performance based on the patch; I get almost twice the speed as a single job running in one database transaction either way. Can someone explain what I should try to set up to get a "best case" and a "worst case" for the patch? Our production databases don't expose any difference, but I'm willing to try to use them to "seed" an artificial case which will. -Kevin
В списке pgsql-hackers по дате отправления: