Re: Further pg_upgrade analysis for many tables
От | Jeff Janes |
---|---|
Тема | Re: Further pg_upgrade analysis for many tables |
Дата | |
Msg-id | CAMkU=1x_JNR=8F_yJnar80uVvBZ5Vt9bbv+=kj3BJU3wh3hc7g@mail.gmail.com обсуждение исходный текст |
Ответ на | Further pg_upgrade analysis for many tables (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: Further pg_upgrade analysis for many tables
|
Список | pgsql-hackers |
On Wed, Nov 7, 2012 at 6:17 PM, Bruce Momjian <bruce@momjian.us> wrote: > As a followup to Magnus's report that pg_upgrade was slow for many > tables, I did some more testing with many tables, e.g.: > ... > > Any ideas? I am attaching my test script. Have you reviewed the thread at: http://archives.postgresql.org/pgsql-performance/2012-09/msg00003.php ? There is a known N^2 behavior when using pg_dump against pre-9.3 servers. There was a proposed patch to pg_dump to work around the problem when it is used against older servers, but it is was not accepted and not entered into a commitfest. For one thing because it there was doubts about how stable it would be at very large scale and it wasn't tested all that thoroughly, and for another, it would be a temporary improvement as once the server itself is upgraded to 9.3, the kludge in pg_dump would no longer be an improvement. The most recent version (that I can find) of that work-around patch is at: http://archives.postgresql.org/pgsql-performance/2012-06/msg00071.php I don't know if that will solve your particular case, but it is probably worth a try. Cheers, Jeff
В списке pgsql-hackers по дате отправления: