Re: Doc patch for truncate.sgml
От | Tom Lane |
---|---|
Тема | Re: Doc patch for truncate.sgml |
Дата | |
Msg-id | 26043.1219947627@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Doc patch for truncate.sgml (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Doc patch for truncate.sgml
|
Список | pgsql-docs |
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
В списке pgsql-docs по дате отправления: