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. +
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 |