On Thu, Dec 13, 2012 at 9:21 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Bruce Momjian <br...@momjian.us> writes: >> On Wed, Dec 12, 2012 at 05:27:39PM -0500, Andrew Dunstan wrote: >>> Actually, the table had been analysed but not vacuumed, so this >>> kinda begs the question what will happen to this value on >>> pg_upgrade? Will people's queries suddenly get slower until >>> autovacuum kicks in on the table? > >> [ moved to hackers list.] > >> Yes, this does seem like a problem for upgrades from 9.2 to 9.3? We can >> have pg_dump --binary-upgrade set these, or have ANALYZE set it. I >> would prefer the later. > > ANALYZE does not set that value, and is not going to start doing so, > because it doesn't scan enough of the table to derive a trustworthy > value. >
Should we do that though ? i.e. scan the entire map and count the number of bits at the end of ANALYZE, like we do at the end of VACUUM ? I recently tried to optimize that code path by not recounting at the end of the vacuum and instead track the number of all-visible bits while scanning them in the earlier phases on vacuum. But it turned out that its so fast to count even a million bits that its probably not worth doing so. > It's been clear for some time that pg_upgrade ought to do something > about transferring the "statistics" columns in pg_class to the new > cluster. This is just another example of why. > +1. Thanks, Pavan -- Pavan Deolasee http://www.linkedin.com/in/pavandeolasee -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers