Re: Testing of parallel restore with current snapshot - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Testing of parallel restore with current snapshot
Date
Msg-id 8628.1242410919@sss.pgh.pa.us
Whole thread Raw
In response to Testing of parallel restore with current snapshot  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Testing of parallel restore with current snapshot  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Josh Berkus <josh@agliodbs.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


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Re: [BUGS] BUG #4796: Recovery followed by backup creates unrecoverable WAL-file
Next
From: Andrew Dunstan
Date:
Subject: Re: Testing of parallel restore with current snapshot