From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Erik Jones <erik(at)myemma(dot)com>, Chris Browne <cbbrowne(at)acm(dot)org>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: why postgresql over other RDBMS |
Date: | 2007-05-25 21:28:43 |
Message-ID: | 22234.1180128523@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Erik Jones wrote:
>> And, to finish up, is there any reason that pg_restore couldn't
>> already work with separate processes working in parallel?
> The problem is that the ordering of objects in the dump is the only
> thing that makes the dump consistent with regards to the dependencies of
> objects. So pg_restore cannot make any assumptions of parallelisability
> of the restoration process of objects in the dump.
That's true at the level of DDL operations, but AFAIK we could
parallelize table-loading and index-creation steps pretty effectively
--- and that's where all the time goes.
A more interesting question is what sort of hardware you need for that
actually to be a win, though. Loading a few tables in parallel sounds
like an ideal recipe for oversaturating your disk bandwidth...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Sullivan | 2007-05-25 21:44:19 | Re: why postgresql over other RDBMS |
Previous Message | Alvaro Herrera | 2007-05-25 21:01:13 | Re: why postgresql over other RDBMS |