pg_upgrade patch application process, and move to /bin?
От | Bruce Momjian |
---|---|
Тема | pg_upgrade patch application process, and move to /bin? |
Дата | |
Msg-id | 201010201901.o9KJ1bj07391@momjian.us обсуждение исходный текст |
Ответ на | pg_upgrade performance with 150k tables (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: pg_upgrade patch application process, and move to /bin?
|
Список | pgsql-hackers |
Bruce Momjian wrote: > I received a private email report yesterday from someone using > pg_upgrade with PG 9.0 who found it took five hours for pg_upgrade to > upgrade a database with 150k tables. Yes, that is a lot of tables, but > pg_upgrade should be able to do better than that. > > I have modified pg_upgrade in git master to cache scandir() and reduce > array lookups and the time is down to 38 minutes. (He prototyped a hash > implementation that was 30 minutes but it was too much code for my > taste.) > > I don't think this is reasonable to backpatch. If anyone else sees > cases for pg_upgrade improvement, please let me know. One more question --- should I be sending pg_upgrade patches to the list for approval? The restructuring patch was large and didn't seem necessary to post, and the speedups were tested by the bug reporter, so I figured those were OK to apply. Oh, and do we want to move pg_upgrade into /bin for 9.1? There was discussion about that six months ago. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: