From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bruce Momjian <bruce@momjian.us>
cc: Andrew Dunstan <andrew@dunslane.net>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [PERFORM] encouraging index-only scans
In-reply-to: <20121213024837.GB22363@momjian.us>
References: <50C8F1EC.9010801@dunslane.net> <15321.1355347953@sss.pgh.pa.us>
	<50C90154.8060103@dunslane.net> <50C904DB.9090305@dunslane.net>
	<20121213024837.GB22363@momjian.us>
Comments: In-reply-to Bruce Momjian <bruce@momjian.us>
	message dated "Wed, 12 Dec 2012 21:48:37 -0500"
Date: Wed, 12 Dec 2012 22:51:38 -0500
Message-ID: <23298.1355370698@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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.

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.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers