From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
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 22:20:55 |
Message-ID: | 20121110222055.GE31383@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Nov 9, 2012 at 04:06:38PM -0800, Jeff Janes wrote:
> 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.
Yes, I see that now:
pg_dump vs. pg_dump --binary-upgrade
9.2 w/ b-u git w/ b-u pg_upgrade
1 0.13 0.13 0.11 0.13 11.73
1000 4.37 8.18 3.98 8.08 28.79
2000 12.98 33.29 12.19 28.11 69.75
4000 47.85 140.62 50.14 138.02 289.82
8000 210.39 604.95 183.00 517.35 1168.60
16000 901.53 2373.79 769.83 1975.94 5022.82
I didn't show the restore numbers yet because I haven't gotten automated
pg_dump --binary-upgrade restore to work yet, but a normal restore for
16k takes 2197.56, so adding that to 1975.94, you get 4173.5, which is
83% of 5022.82. That is a big chunk of the total time for pg_upgrade.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2012-11-10 22:45:54 | Re: Further pg_upgrade analysis for many tables |
Previous Message | Tom Lane | 2012-11-10 21:37:43 | Re: Inadequate thought about buffer locking during hot standby replay |