Received: from localhost (unknown [200.46.204.183])
	by postgresql.org (Postfix) with ESMTP id 134D36500D1
	for <pgsql-docs-postgresql.org@postgresql.org>;
	Thu, 28 Aug 2008 15:20:43 -0300 (ADT)
Received: from postgresql.org ([200.46.204.86])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 24403-08 for <pgsql-docs-postgresql.org@postgresql.org>;
	Thu, 28 Aug 2008 15:20:33 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by postgresql.org (Postfix) with ESMTP id EA32F64FFAA
	for <pgsql-docs@postgresql.org>; Thu, 28 Aug 2008 15:20:34 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m7SIKRe9026044;
	Thu, 28 Aug 2008 14:20:27 -0400 (EDT)
To: Peter Eisentraut <peter_e@gmx.net>
cc: =?UTF-8?B?RGV2cmltIEfDnE5Ew5xa?= <devrim@gunduz.org>,
	pgsql-docs <pgsql-docs@postgresql.org>
Subject: Re: Doc patch for truncate.sgml 
In-reply-to: <48B6E0A6.7030201@gmx.net> 
References: <1219936487.3376.14.camel@laptop.gunduz.org>
	<48B6E0A6.7030201@gmx.net>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
	message dated "Thu, 28 Aug 2008 20:30:14 +0300"
Date: Thu, 28 Aug 2008 14:20:27 -0400
Message-ID: <26043.1219947627@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none
X-Spam-Level: 
X-Archive-Number: 200808/20
X-Sequence-Number: 4960

Peter Eisentraut <peter_e@gmx.net> writes:
> Devrim GÜNDÜZ wrote:
>> !    <command>TRUNCATE</command> rewrites system catalogue entries for
>> !    that table, which makes running <command>ANALYZE</command> on a
>> !    freshly-truncated table is a bad idea, because the statistics will be
>> !    updated to indicate that the table is truly empty.

> If the table is in fact empty, why is it a bad idea to let the 
> statistics reflect that?

I think that this thinking is at least partially obsolete now that
autovacuum/autoanalyze and plan invalidation are in place.  It used to
be that if you truncated a table and then filled it again, any cached
plans that were made while the table was really small would tend to
suck when used with the re-filled table.  But now, autovac will launch
(at least) an ANALYZE against any table that's grown materially, and the
commit of the new analyze stats will result in invalidating any cached
plans.  So the system should be capable of auto-tuning its plans to
changes in table size ... not instantaneously of course, but then you
can't fill a big table instantaneously either.

			regards, tom lane