Re: Further pg_upgrade analysis for many tables

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net>
Subject: Re: Further pg_upgrade analysis for many tables
Date: 2012-11-10 00:06:38
Message-ID: CAMkU=1yP3x3ZZNMfYVOzxVEszM3OhVVASpGnXsEkU4=ODSzW3Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 8, 2012 at 7:25 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
> I did some more research and realized that I was not using --schema-only
> like pg_upgrade uses. With that setting, things look like this:
>
...

For profiling pg_dump in isolation, you should also specify
--binary-upgrade. I was surprised that it makes a big difference,
slowing it down by about 2 fold.

Cheers,

Jeff

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-11-10 00:14:48 Re: Inadequate thought about buffer locking during hot standby replay
Previous Message Daniel Farina 2012-11-09 23:50:22 Re: Inadequate thought about buffer locking during hot standby replay