| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Ants Aasma <ants(at)cybertec(dot)at> |
| Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, 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 17:10:36 |
| Message-ID: | 20121110171036.GA31383@momjian.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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(at)cybertec(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2012-11-10 17:15:58 | Re: Further pg_upgrade analysis for many tables |
| Previous Message | Simon Riggs | 2012-11-10 17:05:31 | Re: Inadequate thought about buffer locking during hot standby replay |