Possible changes to pg_restore

Started by Nonamealmost 16 years ago3 messages
#1Noname
hywel@hmallett.co.uk

Greg Sabino Mullane recently shared a script to split schema-only dump
files into a table creation file and a trigger/index/constraint file, for
restore performance reasons.
(http://blog.endpoint.com/2010/01/splitting-postgres-pgdump-into-pre-and.html)

Would it be possible and worthwhile to add functionality to pg_restore so
that with one switch triggers/indexes/constraints could be ignored, and
with another switch only triggers/indexes/constraints would be restored?

This would then remove the requirement to split the file.

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Noname (#1)
Re: Possible changes to pg_restore

<hywel@hmallett.co.uk> writes:

Would it be possible and worthwhile to add functionality to pg_restore so
that with one switch triggers/indexes/constraints could be ignored, and
with another switch only triggers/indexes/constraints would be restored?

You should probably go back and look at the archives from the last
go-round on that. I believe it was during the 8.4 devel cycle.
Somebody (might have been Simon, but not sure) submitted a patch for
three-part output from pg_dump, it was discussed and sent back for
revision, and the revision never materialized :-(. But IIRC there
was reasonably clear consensus on what the feature ought to look like.

regards, tom lane

#3Andrew Dunstan
andrew@dunslane.net
In reply to: Tom Lane (#2)
Re: Possible changes to pg_restore

Tom Lane wrote:

<hywel@hmallett.co.uk> writes:

Would it be possible and worthwhile to add functionality to pg_restore so
that with one switch triggers/indexes/constraints could be ignored, and
with another switch only triggers/indexes/constraints would be restored?

You should probably go back and look at the archives from the last
go-round on that. I believe it was during the 8.4 devel cycle.
Somebody (might have been Simon, but not sure) submitted a patch for
three-part output from pg_dump, it was discussed and sent back for
revision, and the revision never materialized :-(. But IIRC there
was reasonably clear consensus on what the feature ought to look like.

What is more, the changes done for parallel pg_restore actually did some
of the requisite work of classifying members, as can be seen in this
definition in pg_dump.h:

typedef enum _teSection
{
SECTION_NONE = 1, /* COMMENTs, ACLs, etc; can be
anywhere */
SECTION_PRE_DATA, /* stuff to be processed before data */
SECTION_DATA, /* TABLE DATA, BLOBS, BLOB COMMENTS */
SECTION_POST_DATA /* stuff to be processed after data */
} teSection;

Of course, you'd need to figure our how to handle the SECTION_NONE
entries, but other than that it should be pretty simple, I think.

cheers

andrew