Re: Further pg_upgrade analysis for many tables

From: Ants Aasma <ants(at)cybertec(dot)at>
To: Ants Aasma <ants(at)cybertec(dot)at>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, 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-09 06:20:59
Message-ID: CA+CSw_s=u5NFrhyWxvGpX2yw=d-kGQdXGSDBXMpZpb=se4ENFw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Ants Aasma
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2012-11-09 07:51:40 Re: Proof of concept: auto updatable views [Review of Patch]
Previous Message Amit Kapila 2012-11-09 06:03:32 Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown