Re: Testing of parallel restore with current snapshot

Tom Lane wrote:
> 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.
>
>
>

Other things being equal it schedules things in TOC order, which often
works as we want anyway. I think there's a good case for altering the
name sort order of pg_dump to group sub-objects of a table (indexes,
constraints etc.) together, ie. instead of sorting by <objectname>, we'd
sort by <tablename, objectname>. This would possibly improve the effect
seen in parallel restore without requiring any extra intelligence there.

But I agree it's worth further study. I suspect we can probably beef up
parallel restore quite a bit. My object for this release was to get the
basics working, especially since I started quite late in the development
cycle, and it was a struggle just to make the cut.

cheers

andrew