[DOCS] Doc patch for truncate.sgml
Attached is a doc patch for truncate.sgml. It improves info for TRUNCATE. Thanks to Andrew Sullivan for pointing out this. This is against head, but could be backpatched, too, I believe. Regards, -- Devrim GÜNDÜZ, RHCE devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Index: doc/src/sgml/ref/truncate.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/truncate.sgml,v retrieving revision 1.27 diff -c -r1.27 truncate.sgml *** doc/src/sgml/ref/truncate.sgml 17 May 2008 23:36:27 - 1.27 --- doc/src/sgml/ref/truncate.sgml 28 Aug 2008 14:58:16 - *** *** 34,40 DELETE on each table, but since it does not actually scan the tables it is faster. Furthermore, it reclaims disk space immediately, rather than requiring a subsequent VACUUM !operation. This is most useful on large tables. --- 34,44 DELETE on each table, but since it does not actually scan the tables it is faster. Furthermore, it reclaims disk space immediately, rather than requiring a subsequent VACUUM !operation. This is most useful on large tables. Also, !TRUNCATE rewrites system catalogue entries for !that table, which makes running ANALYZE on a !freshly-truncated table is a bad idea, because the statistics will be !updated to indicate that the table is truly empty. signature.asc Description: This is a digitally signed message part
Re: [DOCS] Doc patch for truncate.sgml
Devrim GÜNDÜZ wrote: Attached is a doc patch for truncate.sgml. It improves info for TRUNCATE. Thanks to Andrew Sullivan for pointing out this. --- 34,44 DELETE on each table, but since it does not actually scan the tables it is faster. Furthermore, it reclaims disk space immediately, rather than requiring a subsequent VACUUM !operation. This is most useful on large tables. Also, !TRUNCATE rewrites system catalogue entries for !that table, which makes running ANALYZE 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 you are making assumptions about certain usage patterns that do not always have to be true, and that are not written down anyway. -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Doc patch for truncate.sgml
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Devrim GÃNDÃZ wrote: >> !TRUNCATE rewrites system catalogue entries for >> !that table, which makes running ANALYZE 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 -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Doc patch for truncate.sgml
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 signature.asc Description: This is a digitally signed message part
