Re: pg_upgrade and statistics
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: Peter Eisentraut <peter_e@gmx.net>, Daniel Farina <daniel@heroku.com>, Greg Stark <stark@mit.edu>, pgsql-hackers <pgsql-hackers@postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2012-03-15T15:48:42Z
Lists: pgsql-hackers
On Thu, Mar 15, 2012 at 10:20:02AM -0500, Kevin Grittner wrote: > Bruce Momjian <bruce@momjian.us> wrote: > > > I think we have two choices --- either migrate the statistics, or > > adopt my approach to generating incremental statistics quickly. > > Does anyone see any other options? > > Would it make any sense to modify the incremental approach to do a > first pass of any tables with target overrides, using the default > GUC setting, and then proceed through the passes you describe for > all tables *except* those? I'm thinking that any overrides were > probably set because the columns are particularly important in terms > of accurate statistics, and that running with different GUC settings > will just be a waste of time for those tables -- if they have a high > setting for any column, they will sample more blocks for every run, > right? I just added text telling users they might want to remove and re-add those per-table statistics. I could try coding up something to store and reset those values, but it is going to be complex, partly because they are in different databases. I would need to create a pg_upgrade schema in every database, store and reset the targets, and restore them once complete. I don't think it makes sense to do the custom targets first because it would likely delay all tables from getting any statistics. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +