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>, "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Review: Revise parallel pg_restore's scheduling heuristic
Date: 2009-07-28 14:28:46
Message-ID: 4A6EC4CE0200002500028E0C@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:

> So far, all tests have shown no difference in performance based on
> the patch;

My testing to that point had been on a "big" machine with 16 CPUs and
128 GB RAM and dozens of spindles. Last night I tried with a dual
core machine with 4 GB RAM and 5 spindles in RAID 5. Still no
difference with the patch.

Any suggestions besides the foreign keys? Should 488 FKs be enough to
matter here? (Barring better suggestions, I'll try the small machine
again tonight with the default configuration, rather than the
optimized one.)

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2009-07-28 14:34:36 Re: [RFC] new digest datatypes, or generic fixed-len hex types?
Previous Message Tom Lane 2009-07-28 13:45:57 Re: Re: [COMMITTERS] pgsql: Reserve the shared memory region during backend startup on