Skip site navigation (1) Skip section navigation (2)

Re: pg_upgrade and statistics

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Daniel Farina <daniel(at)heroku(dot)com>,Greg Stark <stark(at)mit(dot)edu>,pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: pg_upgrade and statistics
Date: 2012-03-15 15:48:42
Message-ID: 20120315154842.GF26534@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Mar 15, 2012 at 10:20:02AM -0500, Kevin Grittner wrote:
> Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-03-15 15:51:36
Subject: Re: pg_upgrade and statistics
Previous:From: Bruce MomjianDate: 2012-03-15 15:46:04
Subject: Re: pg_upgrade and statistics

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group