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

From Bruce Momjian
Subject Re: Further pg_upgrade analysis for many tables
Date
Msg-id 20121110225954.GG31383@momjian.us
Whole thread Raw
In response to Re: Further pg_upgrade analysis for many tables  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: Further pg_upgrade analysis for many tables  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Sat, Nov 10, 2012 at 02:45:54PM -0800, Jeff Janes wrote:
> On Sat, Nov 10, 2012 at 9:15 AM, Bruce Momjian <bruce@momjian.us> wrote:
> > On Fri, Nov  9, 2012 at 04:23:40PM -0800, Jeff Janes wrote:
> >> On Fri, Nov 9, 2012 at 3:06 PM, Bruce Momjian <bruce@momjian.us> wrote:
> >> >
> >> > Again, using SERIAL?
> >>
> >> Yep.
> >
> > Odd why yours is so much after.
> 
> You didn't build git head under --enable-cassert, did you?

Yikes, you got me!  I have not done performance testing in so long, I
had forgotten I changed my defaults.  New numbers to follow.  Sorry.

> Any chance you can do a oprofile or gprof of head's pg_dump dumping
> out of head's server?  That really should be a lot faster (since
> commit eeb6f37d89fc60c6449ca12ef9e) than dumping out of 9.2 server.
> If it is not for you, I don't see how to figure it out without a
> profile of the slow system.

Yes, coming.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Further pg_upgrade analysis for many tables
Next
From: Amit kapila
Date:
Subject: Re: [PATCH] Patch to compute Max LSN of Data Pages