Re: Further pg_upgrade analysis for many tables

On Tue, Nov 27, 2012 at 09:35:10PM -0800, Jeff Janes wrote:
> 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.

I was going to ask you that. :-) Let me run a test with your patch
now.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +