Re: pg_upgrade and statistics
От | Bruce Momjian |
---|---|
Тема | Re: pg_upgrade and statistics |
Дата | |
Msg-id | 20120314002251.GA9132@momjian.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade and statistics ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: pg_upgrade and statistics
Re: pg_upgrade and statistics |
Список | pgsql-hackers |
On Tue, Mar 13, 2012 at 05:33:29PM -0500, Kevin Grittner wrote: > Bruce Momjian <bruce@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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: