Re: dump_all/restore times?
От | nolan@celery.tssi.com |
---|---|
Тема | Re: dump_all/restore times? |
Дата | |
Msg-id | 20030716233912.26461.qmail@celery.tssi.com обсуждение исходный текст |
Ответ на | Re: dump_all/restore times? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
> I have a sneaking suspicion that creation of foreign key constraints may > be unreasonably inefficient during a restore, too. Have not had a > chance to check up on it though. Next time you run such a restore, > could you turn on log_statement and log_timestamp (or log_duration if > you have it) so we can see which steps take the most time? No foreign keys, but a lot of fairly large tables (by my usual standards), several of which are multiply indexed. It didn't seem to get into the indexing part until the last 2-3 hours, I think most of that time was just loading data. I can run the load again, this system was set up so I could develop more familiarity with FreeBSD and to have a place to run CVS, the data is just there to have something to test 7.4 with. I was also planning to set up 7.3.3 on it (probably with a subset of the data) so that I could do some comparative timings during beta testing. I will try the restore under 7.3.3 to see if it performs much differently, though after reading Joe's note I suspect that's probably just how long it takes on this box. -- Mike Nolan
В списке pgsql-general по дате отправления: