Re: Further pg_upgrade analysis for many tables - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: Further pg_upgrade analysis for many tables
Date
Msg-id CAMkU=1x_JNR=8F_yJnar80uVvBZ5Vt9bbv+=kj3BJU3wh3hc7g@mail.gmail.com
Whole thread Raw
In response to Further pg_upgrade analysis for many tables  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Further pg_upgrade analysis for many tables
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: AutoVacuum starvation from sinval messages
Next
From: Jeff Janes
Date:
Subject: Re: AutoVacuum starvation from sinval messages