public inbox for [email protected]
help / color / mirror / Atom feedDoc patch for truncate.sgml
4+ messages / 3 participants
[nested] [flat]
* Doc patch for truncate.sgml
@ 2008-08-28 15:14 Devrim GÜNDÜZ <[email protected]>
0 siblings, 1 reply; 4+ messages in thread
From: Devrim GÜNDÜZ @ 2008-08-28 15:14 UTC (permalink / raw)
To: pgsql-docs
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
Attachments:
[text/x-patch] truncate-sgml.patch (1.3K, 2-truncate-sgml.patch)
download | inline diff:
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 -0000 1.27
--- doc/src/sgml/ref/truncate.sgml 28 Aug 2008 14:58:16 -0000
***************
*** 34,40 ****
<command>DELETE</command> 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 <command>VACUUM</command>
! operation. This is most useful on large tables.
</para>
</refsect1>
--- 34,44 ----
<command>DELETE</command> 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 <command>VACUUM</command>
! operation. This is most useful on large tables. Also,
! <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.
</para>
</refsect1>
[application/pgp-signature] signature.asc (197B, 3-signature.asc)
download
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Doc patch for truncate.sgml
@ 2008-08-28 17:30 Peter Eisentraut <[email protected]>
parent: Devrim GÜNDÜZ <[email protected]>
0 siblings, 1 reply; 4+ messages in thread
From: Peter Eisentraut @ 2008-08-28 17:30 UTC (permalink / raw)
To: Devrim GÜNDÜZ <[email protected]>; +Cc: pgsql-docs
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 ----
> <command>DELETE</command> 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 <command>VACUUM</command>
> ! operation. This is most useful on large tables. Also,
> ! <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.
> </para>
> </refsect1>
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.
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Doc patch for truncate.sgml
@ 2008-08-28 18:20 Tom Lane <[email protected]>
parent: Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 4+ messages in thread
From: Tom Lane @ 2008-08-28 18:20 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Devrim GÜNDÜZ <[email protected]>; pgsql-docs
Peter Eisentraut <[email protected]> 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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Doc patch for truncate.sgml
@ 2008-08-28 18:48 Devrim GÜNDÜZ <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 0 replies; 4+ messages in thread
From: Devrim GÜNDÜZ @ 2008-08-28 18:48 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; 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
Attachments:
[application/pgp-signature] signature.asc (197B, 2-signature.asc)
download
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2008-08-28 18:48 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2008-08-28 15:14 Doc patch for truncate.sgml Devrim GÜNDÜZ <[email protected]>
2008-08-28 17:30 ` Peter Eisentraut <[email protected]>
2008-08-28 18:20 ` Tom Lane <[email protected]>
2008-08-28 18:48 ` Devrim GÜNDÜZ <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox