Stephen Frost <[EMAIL PROTECTED]> writes: > * daveg ([EMAIL PROTECTED]) wrote: >> One observation, indexes should be built right after the table data >> is loaded for each table, this way, the index build gets a hot cache >> for the table data instead of having to re-read it later as we do now.
> That's not how pg_dump has traditionally worked, and the point of this > patch is to add options to easily segregate the main pieces of the > existing pg_dump output (main schema definition, data dump, key/index > building). You suggestion brings up an interesting point that should > pg_dump's traditional output structure change the "--schema-post-load" > set of objects wouldn't be as clear to newcomers since the load and the > indexes would be interleaved in the regular output. Yeah. Also, that is pushing into an entirely different line of development, which is to enable multithreaded pg_restore. The patch at hand is necessarily incompatible with that type of operation, and wouldn't be used together with it. As far as the documentation/definition aspect goes, I think it should just say the parts are * stuff needed before you can load the data * the data * stuff needed after loading the data and not try to be any more specific than that. There are corner cases that will turn any simple breakdown into a lie, and I doubt that it's worth trying to explain them all. (Take a close look at the dependency loop breaking logic in pg_dump if you doubt this.) I hadn't realized that Simon was using "pre-schema" and "post-schema" to name the first and third parts. I'd agree that this is confusing nomenclature: it looks like it's trying to say that the data is the schema, and the schema is not! How about "pre-data and "post-data"? regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches