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

From Tom Lane
Subject Re: Further pg_upgrade analysis for many tables
Date
Msg-id 26860.1352737388@sss.pgh.pa.us
Whole thread Raw
In response to Re: Further pg_upgrade analysis for many tables  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> On Fri, Nov  9, 2012 at 12:50:34AM -0500, Tom Lane wrote:
>> The hash_seq_search time is probably mostly associated with
>> AtEOXact_RelationCache, which is run during transaction commit and scans
>> the relcache hashtable looking for tables created in the current
>> transaction.  So that's about 50% of the runtime going into that one
>> activity.

> Thanks for finding this.  What is odd is that I am not seeing non-linear
> restores at 16k in git head, so I am confused how something that
> consumes ~50% of backend time could still perform linearly.  Would this
> consume 50% at lower table counts?

No, the cost from that is O(N^2), though with a pretty small multiplier.
16K tables is evidently where the cost reaches the point of being
significant --- if you went up from there, you'd probably start to
notice an overall O(N^2) behavior.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: TRUNCATE SERIALIZABLE and frozen COPY
Next
From: "Karl O. Pinc"
Date:
Subject: Doc patch: Document names of automatically created constraints and indexes