Re: Testing of parallel restore with current snapshot

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: Testing of parallel restore with current snapshot
Date: 2009-05-15 18:08:39
Message-ID: 8628.1242410919@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Andrew's latest algorithm tends to result in building indexes on the
> same table at the same time. This is excellent for most users; I'm on a
> client's site which is I/O bound and that approach is speeding up
> parallel load about 20% compared to the beta1 version.

Hmph ... that seems like a happenstance, because there isn't anything in
there that is specifically trying to organize things that way. AFAIK
it's only accounting for required dependencies, not for possible
performance implications of scheduling various tasks together.

> In other words, don't mess with it now. I think it's perfect. ;-)

I don't want to mess with it right now either, but perhaps we should
have a TODO item to improve the intelligence of parallel restore so that
it really does try to do things this way.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2009-05-15 18:28:28 Re: Testing of parallel restore with current snapshot
Previous Message Simon Riggs 2009-05-15 17:18:56 Re: [HACKERS] Re: BUG #4796: Recovery followed by backup creates unrecoverable WAL-file