From: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
---|---|
To: | "Mario Weilguni" <mweilguni(at)sime(dot)com> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_restore oddity? |
Date: | 2007-10-12 12:34:37 |
Message-ID: | 470F69DD.1080600@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Mario Weilguni wrote:
> I cannot use "-1" for performance, because some gist stuff has changed
> and the restore fails. But there seems to be no option for pg_restore to
> use transactions for data restore, so it's very very slow (one million
> records, each obviously in it's own transaction - because a separate
> session "select count(1) from logins" shows a growing number).
By default, pg_dump/pg_restore uses a COPY command for each table, and
each COPY executes as a single transaction, so you shouldn't see the row
count growing like that. Is the dump file in --inserts format?
> It would be nice to use transactions for the data stuff itself, but not
> for schema changes or functions. I know I can use separate pg_restore
> runs for schema and data, but it's complicated IMHO.
pg_restore -s foo
pg_restore -a -1 foo
doesn't seem too complicated to me. Am I missing something?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Mario Weilguni | 2007-10-12 12:57:52 | Re: pg_restore oddity? |
Previous Message | Deblauwe Gino | 2007-10-12 12:27:31 | Re: First steps with 8.3 and autovacuum launcher |