Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 02FE564FD22 for ; Thu, 28 Aug 2008 15:47:42 -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 49327-08 for ; Thu, 28 Aug 2008 15:47:27 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from orion.asenkron.com (orion.asenkron.com [64.15.152.21]) by postgresql.org (Postfix) with ESMTP id 5537764FD10 for ; Thu, 28 Aug 2008 15:47:29 -0300 (ADT) Received: from localhost (unknown [127.0.0.1]) by orion.asenkron.com (Postfix) with ESMTP id 4B62ABD0007; Thu, 28 Aug 2008 18:43:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at orion.asenkron.com Received: from orion.asenkron.com ([127.0.0.1]) by localhost (orion.asenkron.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIKjeQj5bBnF; Thu, 28 Aug 2008 21:43:28 +0300 (EEST) Received: from [192.168.1.4] (unknown [88.251.52.116]) by orion.asenkron.com (Postfix) with ESMTPA id 0D1A5BD0005; Thu, 28 Aug 2008 21:43:25 +0300 (EEST) Subject: Re: Doc patch for truncate.sgml From: Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= To: Tom Lane Cc: Peter Eisentraut , pgsql-docs In-Reply-To: <26043.1219947627@sss.pgh.pa.us> References: <1219936487.3376.14.camel@laptop.gunduz.org> <48B6E0A6.7030201@gmx.net> <26043.1219947627@sss.pgh.pa.us> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-1gNpVNBP15stQWIAw33S" Date: Thu, 28 Aug 2008 21:48:18 +0300 Message-Id: <1219949298.3376.24.camel@laptop.gunduz.org> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) 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/21 X-Sequence-Number: 4961 --=-1gNpVNBP15stQWIAw33S Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, On Thu, 2008-08-28 at 14:20 -0400, Tom Lane wrote: > > If the table is in fact empty, why is it a bad idea to let the=20 > > statistics reflect that? >=20 > 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. Good point. --=20 Devrim G=C3=9CND=C3=9CZ, RHCE devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org --=-1gNpVNBP15stQWIAw33S Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAki28vAACgkQtl86P3SPfQ43ewCcDukob1E+MnbBh6ObAHbqYg2t 8pkAn3uaZK0Quj9VR5GKDt9R9qg4OhSq =XM0v -----END PGP SIGNATURE----- --=-1gNpVNBP15stQWIAw33S--