From: | Devrim GÜNDÜZ <devrim(at)gunduz(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-docs <pgsql-docs(at)postgresql(dot)org> |
Subject: | Re: Doc patch for truncate.sgml |
Date: | 2008-08-28 18:48:18 |
Message-ID: | 1219949298.3376.24.camel@laptop.gunduz.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
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
> > 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.
Good point.
--
Devrim GÜNDÜZ, RHCE
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2008-09-03 16:59:42 | Re: Backslash Escape Sequences |
Previous Message | Tom Lane | 2008-08-28 18:20:27 | Re: Doc patch for truncate.sgml |