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!



---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
      choose an index scan if your joining column's datatypes do not
      match

Reply via email to