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
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 |