From: | Mario Weilguni <mweilguni(at)sime(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_restore oddity? |
Date: | 2007-10-12 12:57:52 |
Message-ID: | 470F6F50.70706@sime.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas schrieb:
> 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?
>
>
You are right, it was my fault. I was confused about the pg_dump syntax,
and used "-d" (the "-d" because pg_restore needs it for the destination
database, not the dump itself), so it was using "--inserts".
Everything is working fine. I've done dump/restores cycles a hundreds
times, and now such a mistake. I can't believe it.
Seems like I need to take some vacations.
Thanks for the help!
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2007-10-12 13:03:47 | Re: Locales and Encodings |
Previous Message | Heikki Linnakangas | 2007-10-12 12:34:37 | Re: pg_restore oddity? |