Re: Review: Revise parallel pg_restore's scheduling heuristic

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Review: Revise parallel pg_restore's scheduling heuristic
Date: 2009-07-27 15:54:23
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)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.


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2009-07-27 16:02:32 Re: [RFC] new digest datatypes, or generic fixed-len hex types?
Previous Message Robert Haas 2009-07-27 15:41:05 Re: When is a record NULL?