On Tue, Mar 13, 2012 at 05:33:29PM -0500, Kevin Grittner wrote: > Bruce Momjian <br...@momjian.us> wrote: > > > What is the target=10 duration? I think 10 is as low as we can > > acceptably recommend. Should we recommend they run vacuumdb > > twice, once with default_statistics_target = 4, and another with > > the default? > > Here are the results at various settings. > > 1 : 172198.892 ms > 2 : 295536.814 ms > 4 : 474319.826 ms > 10 : 750458.312 ms > 100 : 3433794.609 ms
Thanks, good numbers to know. > I'm not sure what's best for a general approach to the problem. For > my own part, I'd be inclined to cherry-pick tables if I were in a > hurry. > > I hope we at least bring over relpages and reltuples, to give the > optimizer *some* clue what it's looking at. I wouldn't thing those > would be changing semantics or format very often. True, but we don't migrate them either. This is the exact same problem you would have restoring a pg_dump backup. The improvement needs to go into pg_dump, and then pg_upgrade can make use of it. Another idea is to just copy over pg_statistic like we copy of pg_largeobject now, and force autovacuum to run. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
