Re: Further pg_upgrade analysis for many tables

On Tue, Nov 27, 2012 at 8:13 PM, Bruce Momjian <bruce(at)momjian(dot)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