On Tue, Nov 27, 2012 at 8:13 PM, Bruce Momjian <br...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
