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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2012-03-13 21:42:41 Re: pg_upgrade and statistics
Previous Message Greg Stark 2012-03-13 21:28:33 Re: pg_upgrade and statistics