DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	b=US8oijibgyPn8eCm0JbIbRgCCZIouks0mtch/ElSmwVsQHKZQ7tnKq3iFveGFNtSjR
	fI8X5wpYfT5cmCepiE5QZrTjZ/Op/rtQIfWUF0KwNJ/TszP6Iuoey7+SSa8AGvhCVRQh
	v17NXRGZyIpszd35NCRY0uiDpg9nC5JbsEfq8=
MIME-Version: 1.0
In-Reply-To: <22926.1306343067@sss.pgh.pa.us>
References: <4DD28F73.6010108@25th-floor.com> <25017.1306291669@sss.pgh.pa.us>
	<4DDCA801.70805@25th-floor.com> <19738.1306338472@sss.pgh.pa.us>
	<BANLkTi=973Arh-nXLO6YFP7_ZTCeNp-X7w@mail.gmail.com>
	<22497.1306341699@sss.pgh.pa.us>
	<BANLkTim7YNLBBDUT9qXZrO2biuwDZ3kjyg@mail.gmail.com>
	<22926.1306343067@sss.pgh.pa.us>
Date: Wed, 25 May 2011 13:15:59 -0400
Message-ID: <BANLkTimVhdO_bKQagRsH0OLp7MxgJZDryg@mail.gmail.com>
Subject: Re: [ADMIN] pg_class reltuples/relpages not updated by
	autovacuum/vacuum
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Florian Helmberger <fh@25th-floor.com>, pgsql-hackers@postgresql.org,
	Alvaro Herrera <alvherre@commandprompt.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, May 25, 2011 at 1:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> [ shrug... ] =A0When you don't have complete information, it's *always*
> the case that you will sometimes make a mistake. =A0That's not
> justification for paralysis, especially not when the existing code is
> demonstrably broken.
>
> What occurs to me after thinking a bit more is that the existing tuple
> density is likely to be only an estimate, too (one coming from the last
> ANALYZE, which could very well have scanned even less of the table than
> VACUUM did). =A0So what I now think is that both VACUUM and ANALYZE ought
> to use a calculation of the above form to arrive at a new value for
> pg_class.reltuples. =A0In both cases it would be pretty easy to track the
> number of pages we looked at while counting tuples, so the same raw
> information is available.
>
>> I am wondering, though, why we're not just inserting a special-purpose
>> hack for TOAST tables.
>
> Because the problem is not specific to TOAST tables. =A0As things
> currently stand, we will accept the word of an ANALYZE as gospel even if
> it scanned 1% of the table, and completely ignore the results from a
> VACUUM even if it scanned 99% of the table. =A0This is not sane.

I agree that if VACUUM scanned 99% of the table, it's probably fine to
use its numbers.  It's also fine to use the numbers from ANALYZE,
because those pages are chosen randomly.  What bothers me is the idea
of using a small *non-random* sample, and I'm not sure that
incorporating possibly-bogus results slowly is any better than
incorporating them quickly.

--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company