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?  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: pg_upgrade performance with 150k tables
Следующее
От: David Fetter
Дата:
Сообщение: Re: WIP: extensible enums