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 20121110171036.GA31383@momjian.us
Whole thread Raw
In response to Re: Further pg_upgrade analysis for many tables  (Ants Aasma <ants@cybertec.at>)
Responses Re: Further pg_upgrade analysis for many tables  (Ants Aasma <ants@cybertec.at>)
List pgsql-hackers
On Fri, Nov  9, 2012 at 08:20:59AM +0200, Ants Aasma wrote:
> On Fri, Nov 9, 2012 at 7:53 AM, Ants Aasma <ants@cybertec.at> wrote:
> > I also took two profiles (attached). AtEOXact_RelationCache seems to
> > be the culprit for the quadratic growth.
> 
> One more thing that jumps out as quadratic from the profiles is
> transfer_all_new_dbs from pg_upgrade (20% of total CPU time at 64k).
> Searching for non-primary files loops over the whole file list for
> each relation. This would be a lot faster if we would sort the file
> list first and use binary search to find the related files.

I am confused why you see a loop.  transfer_all_new_dbs() does a
merge-join of old/new database names, then calls gen_db_file_maps(),
which loops over the relations and calls create_rel_filename_map(),
which adds to the map via array indexing.   I don't see any file loops
in there --- can you be more specific?

--  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: Simon Riggs
Date:
Subject: Re: Inadequate thought about buffer locking during hot standby replay
Next
From: Bruce Momjian
Date:
Subject: Re: Further pg_upgrade analysis for many tables