Re: pg_upgrade and statistics
От | Bruce Momjian |
---|---|
Тема | Re: pg_upgrade and statistics |
Дата | |
Msg-id | 20120316225504.GE28340@momjian.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade and statistics (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-hackers |
On Thu, Mar 15, 2012 at 11:46:04AM -0400, Bruce Momjian wrote: > On Thu, Mar 15, 2012 at 11:15:42AM -0400, Andrew Dunstan wrote: > > You're not the only person who could do that. I don't think this is > > all down to you. It should just be understood that if the stats > > format is changed, adjusting pg_upgrade needs to be part of the > > change. When we modified how enums worked, we adjusted pg_upgrade at > > the same time. That sort of thing seems totally reasonable to me. > > > > I haven't looked at it, but I'm wondering how hard it is going to be > > in practice? > > Well, the reason I am not recommending migration is because the work > will _not_ fall on me, but rather on the larger community of developers, > who might or might not care about pg_upgrade. (I am concerned about > pg_upgrade retarding development progress.) > > We are already telling developers not to change the binary storage > format without considering pg_upgrade --- do we want to do the same for > optimizer statistics? Does the optimizer statistics format change more > frequently than the storage format? I think the answer is yes. Does it > change too frequently to require migration work? I don't know the > answer to that, partly because I would not be the one doing the work. > > Also, considering we are on the last 9.2 commit-fest, I doubt we can get > something working for statistics migration for 9.2, I think the > incremental statistics build approach is our only way to improve this > for 9.2, and frankly, 9.1 users can also use the script once I post it. > > FYI, I have not received a huge number of complaints about the old > analyze recommendation --- a few, but not a flood. The incremental > build approach might be good enough. > > My wild guess is that even if we migrated all statistics, the migrated > statistics will still not have any improvements we have made in > statistics gathering, meaning there will still be some kind of analyze > process necessary, hopefully just on the affected tables --- that would > be shorter, but perhaps not shorter enough to warrant the work in > migrating the statistics. > > I am attaching the updated script and script output. > > Please, don't think I am ungrateful for the offers of help in migrating > statistics. I just remember how complex the discussion was when we > modified the enum improvements to allow pg_upgrade, and how complex the > checksum discussion was related to pg_upgrade. Applied to git head for PG 9.2. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: