Re: Review: Revise parallel pg_restore's scheduling heuristic - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Review: Revise parallel pg_restore's scheduling heuristic
Date
Msg-id 4A6D875F0200002500028D83@gw.wicourts.gov
Whole thread Raw
In response to Re: Review: Revise parallel pg_restore's scheduling heuristic  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Review: Revise parallel pg_restore's scheduling heuristic  (Andrew Dunstan <andrew@dunslane.net>)
Re: Review: Revise parallel pg_restore's scheduling heuristic  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: When is a record NULL?
Next
From: Andrew Dunstan
Date:
Subject: Re: [RFC] new digest datatypes, or generic fixed-len hex types?