Re: Review: Revise parallel pg_restore's scheduling heuristic

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Review: Revise parallel pg_restore's scheduling heuristic
Date: 2009-07-30 17:29:34
Message-ID: 4A71922E02000025000290FD@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> I think we've pretty much established that it doesn't make things
> *worse*, so I'm sort of inclined to go ahead and apply it. The
> theoretical advantage of eliminating O(N^2) search behavior seems
> like reason enough, even if it takes a ridiculous number of tables
> for that to become significant.

Agreed, although I'm having some concerns about whether this should
proceed based exclusively on my benchmarks. On a thread on the
performance list, people are talking about restores which go several
times faster with parallel restore (compared to a single job). On my
hardware, I haven't even gotten it to run twice as fast. This means
that parallel restore is not a good fit for servers like we have, at
least with databases like we have, which means it's probably a poor
environment to get benchmarks for this patch. :-(

Can we get someone who has benchmarks showing parallel restore to be
eight times the speed of a single job to benchmark with this patch,
just for confirmation?

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-07-30 18:31:31 Re: fix: plpgsql: return query and dropped columns problem
Previous Message Robert Haas 2009-07-30 17:29:16 Re: Review: Revise parallel pg_restore's scheduling heuristic