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

Re: pg_upgrade and statistics

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>,Daniel Farina <daniel(at)heroku(dot)com>,pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade and statistics
Date: 2012-03-13 21:40:09
Message-ID: 20120313214009.GA23790@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, Mar 13, 2012 at 09:28:33PM +0000, Greg Stark wrote:
> hmph. One thing that could speed up analyze on raid arrays would be
> doing prefetching so more than one spindle can be busy. Sacrificing
> statistical accuracy by reading a less random sample on contiguous
> blocks of rows would also be faster but less accurate -- we've gone
> around on that topic at least once in the past.
> 
> +1 to the idea that pg_upgrade could run analyze with a
> statistics_target of 10 and then let autovacuum analyze it again later
> with the normal targets at its leisure.

Well, that's going to take quite a bit of infrastructure.  We can tell
users to use the PGOPTIONS setting when they run vacuumdb, but we are
going to need some way to cause autovacuum to run later with a higher
statistics target  ---  right now I don't think autovacuum cares how
large a statistics target the previous analyze run used.  It might be a
simple case of causing autovacuum to analyze if it has statistics that
don't match the current statistics target, but I don't think autovacuum
has easy access to those values.

-- 
  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: Bruce MomjianDate: 2012-03-13 21:42:41
Subject: Re: pg_upgrade and statistics
Previous:From: Greg StarkDate: 2012-03-13 21:28:33
Subject: Re: pg_upgrade and statistics

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