Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Tj97k-000668-Kt for pgsql-hackers@arkaria.postgresql.org; Thu, 13 Dec 2012 13:46:52 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1Tj97k-0000Tu-4v for pgsql-hackers@arkaria.postgresql.org; Thu, 13 Dec 2012 13:46:52 +0000 Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Tj97i-0000SS-3Q for pgsql-hackers@postgresql.org; Thu, 13 Dec 2012 13:46:50 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Tj97f-0000UO-VT for pgsql-hackers@postgresql.org; Thu, 13 Dec 2012 13:46:49 +0000 Received: from bruce by momjian.us with local (Exim 4.72) (envelope-from ) id 1Tj97d-0004E0-27; Thu, 13 Dec 2012 08:46:45 -0500 Date: Thu, 13 Dec 2012 08:46:45 -0500 From: Bruce Momjian To: Simon Riggs Cc: Tom Lane , Andrew Dunstan , PostgreSQL-development Subject: Re: [PERFORM] encouraging index-only scans Message-ID: <20121213134645.GA15258@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> <23298.1355370698@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On Thu, Dec 13, 2012 at 09:40:40AM +0000, Simon Riggs wrote: > On 13 December 2012 03:51, Tom Lane wrote: > > >> 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. > > ISTM that ANALYZE doesn't need to scan the table to do this. The > vismap is now trustworthy and we can scan it separately on ANALYZE. > > More to the point, since we run ANALYZE more frequently than we run > VACUUM, the value stored by the last VACUUM could be very stale. Wouldn't inserts affect the relallvisible ratio, but not cause a vacuum? Seems we should be having analyze update this independent of pg_upgrade needing it. Also, why is this in pg_class? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers