Re: Further pg_upgrade analysis for many tables

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: 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-08 17:30:11
Message-ID: 509BEC23.90203@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/7/12 9:17 PM, Bruce Momjian wrote:
> As a followup to Magnus's report that pg_upgrade was slow for many
> tables, I did some more testing with many tables, e.g.:
>
> CREATE TABLE test991 (x SERIAL);
>
> I ran it for 0, 1k, 2k, ... 16k tables, and got these results:
>
> tables pg_dump restore pg_upgrade(increase)
> 0 0.30 0.24 11.73(-)
> 1000 6.46 6.55 28.79(2.45x)
> 2000 29.82 20.96 69.75(2.42x)
> 4000 95.70 115.88 289.82(4.16x)
> 8000 405.38 505.93 1168.60(4.03x)
> 16000 1702.23 2197.56 5022.82(4.30x)

I can reproduce these numbers, more or less. (Additionally, it ran out
of shared memory with the default setting when dumping the 8000 tables.)

But this issue seems to be entirely the fault of sequences being
present. When I replace the serial column with an int, everything
finishes within seconds and scales seemingly linearly.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit kapila 2012-11-08 17:33:54 Re: Performance Improvement by reducing WAL for Update Operation
Previous Message Tom Lane 2012-11-08 17:22:39 Re: Proof of concept: auto updatable views [Review of Patch]