On Thu, Dec 13, 2012 at 9:21 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Bruce Momjian <bruce@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
