DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	b=Kr4wZjzbfrpBqXEqBr23uBYI18GJSJzqOLnoxBwgFMv3hcrx2ebpS4Z+JDQ2CobzYv
	fmF13SAPCrynPdAnebV9Tyg73K1PCKECmovEBMSKMHB+mGKuoLPM9ALZb/Jw1jFwQVa9
	swGxwXGt1KUWrlctdnCsKmpFUC0gP93WXdJVM=
MIME-Version: 1.0
In-Reply-To: <1306342228-sup-2964@alvh.no-ip.org>
References: <4DD28F73.6010108@25th-floor.com> <25017.1306291669@sss.pgh.pa.us>
	<4DDCA801.70805@25th-floor.com> <19738.1306338472@sss.pgh.pa.us>
	<1306339028-sup-6948@alvh.no-ip.org> <22173.1306340636@sss.pgh.pa.us>
	<4DDCE9F4020000250003DC48@gw.wicourts.gov>
	<1306342228-sup-2964@alvh.no-ip.org>
From: =?ISO-8859-1?Q?C=E9dric_Villemain?= <cedric.villemain.debian@gmail.com>
Date: Wed, 25 May 2011 19:24:01 +0200
Message-ID: <BANLkTimyfvQXsLswzBCV5PFi+NN_TeDZ+g@mail.gmail.com>
Subject: Re: [ADMIN] pg_class reltuples/relpages not updated by
	autovacuum/vacuum
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Kevin Grittner <kevin.grittner@wicourts.gov>,
 Tom Lane <tgl@sss.pgh.pa.us>,
	Florian Helmberger <fh@25th-floor.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2011/5/25 Alvaro Herrera <alvherre@commandprompt.com>:
> Excerpts from Kevin Grittner's message of mi=E9 may 25 12:37:24 -0400 201=
1:
>> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> > I don't know what client-side code might be looking at
>> > relpages/reltuples.
>>
>> I know that I find reltuples useful for getting an "accurate enough"
>> sense of rows in a table (or set of tables) without resorting to
>> count(*). =A0I'd be OK with any two of pages, tuples, and density; but
>> dropping to one would make databases harder to manage, IMV.
>>
>> Personally, I don't have much code that uses those columns;
>> eliminating an existing column wouldn't involve much pain for me as
>> long as it could still be derived.
>
> Well, we only actually need to store one number, because you can figure
> out a much more precise number-of-pages figure with pg_relation_size()
> divided by configured page size.
>
> (We feel free to hack around catalogs in other places, and we regularly
> break pgAdmin and the like when we drop columns -- people just live with
> it and update their tools. =A0I don't think it's such a big deal in this
> particular case.)

I may miss something but we need relation size in costsize.c even if
we have a reldensity (or we need a reltuples). Else what values should
be used to estimate the relation size ? (pg_relation_size() goes down
to kernel/fs to ask the stat.st_size, is it really what we want?)


>
> --
> =C1lvaro Herrera <alvherre@commandprompt.com>
> The PostgreSQL Company - Command Prompt, Inc.
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>


--=20
C=E9dric Villemain=A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 2ndQuadrant
http://2ndQuadrant.fr/=A0 =A0=A0 PostgreSQL : Expertise, Formation et Suppo=
rt