Re: parallel pg_restore - WIP patch
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Russell Smith <mr-russ@pws.com.au>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Jeffrey Baker <jwbaker@gmail.com>
Date: 2008-09-29T23:38:58Z
Lists: pgsql-hackers
Attachments
- parallel_restore_4.patch (text/x-patch) patch
Stefan Kaltenbrunner wrote: > Tom Lane wrote: >> Andrew Dunstan <andrew@dunslane.net> writes: >>> Tom Lane wrote: >>>> Um, FKs could conflict with each other too, so that by itself isn't >>>> gonna fix anything. >> >>> Good point. Looks like we'll need to make a list of "can't run in >>> parallel with" items as well as strict dependencies. >> >> Yeah, I was just thinking about that. The current archive format >> doesn't really carry enough information for this. I think there >> are two basic solutions we could adopt: >> >> * Extend the archive format to provide some indication that "restoring >> this object requires exclusive access to these dependencies". >> >> * Hardwire knowledge into pg_restore that certain types of objects >> require exclusive access to their dependencies. >> >> The former seems more flexible, as well as more in tune with the basic >> design assumption that pg_restore shouldn't have a lot of knowledge >> about individual archive object types. But it would mean that you >> couldn't use parallel restore with any pre-8.4 dumps. In the long run >> that's no big deal, but in the short run it's annoying. > > hmm not sure how much of a problem that really is - we usually > recommend to use the pg_dump version of the target database anyway. > > > > We don't really need a huge amount of hardwiring as it turns out. Here is a version of the patch that tries to do what's needed in this area. cheers andrew