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

From Jeff Janes
Subject Re: Further pg_upgrade analysis for many tables
Date
Msg-id CAMkU=1ydpUgYbrz4W_QPfzeunRBEnbbcOR2SCJApceN78=6_1A@mail.gmail.com
Whole thread Raw
In response to Re: Further pg_upgrade analysis for many tables  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Further pg_upgrade analysis for many tables
Re: Further pg_upgrade analysis for many tables
List pgsql-hackers
On Tue, Nov 27, 2012 at 8:13 PM, Bruce Momjian <bruce@momjian.us> wrote:
>
> I have some new interesting results (in seconds, test script attached):
>
>             ---- -Fc ----  ------- dump | pg_restore/psql ------  - pg_upgrade -
>             dump  restore   -Fc    -Fc|-1  -Fc|-j   -Fp    -Fp|-1   git    patch
>     1       0.14    0.08    0.14    0.16    0.19    0.13    0.15   11.04   13.07
>  1000       3.08    3.65    6.53    6.60    5.39    6.37    6.54   21.05   22.18
>  2000       6.06    6.52   12.15   11.78   10.52   12.89   12.11   31.93   31.65
>  4000      11.07   14.68   25.12   24.47   22.07   26.77   26.77   56.03   47.03
>  8000      20.85   32.03   53.68   45.23   45.10   59.20   51.33  104.99   85.19
> 16000      40.28   88.36  127.63   96.65  106.33  136.68  106.64  221.82  157.36
> 32000      93.78  274.99  368.54  211.30  294.76  376.36  229.80  544.73  321.19
> 64000     197.79 1109.22 1336.83  577.83 1117.55 1327.98  567.84 1766.12  763.02
>
> I tested custom format with pg_restore -j and -1, as well as text
> restore.  The winner was pg_dump -Fc | pg_restore -1;

I don't have the numbers at hand, but if my relcache patch is
accepted, then "-1" stops being faster.

-1 gets rid of the AtOEXAct relcache N^2 behavior, but at the cost of
invoking a different N^2, that one in the stats system.


Cheers,

Jeff



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Bugs in CREATE/DROP INDEX CONCURRENTLY
Next
From: Amit Kapila
Date:
Subject: Re: Review: Patch to compute Max LSN of Data Pages