Drop any statistics of table after it's truncated
Hi all,
I found that the statistics are still remained after it's truncated.
In addition, the analyzing ignores table does not have any tuple.
After table truncated, the entry of statistics continues to remain
unless insertion and analyzing are executed.
There is reason why statistics are remained?
Attached patch is one line patch adds RemoveStatistics() into
ExecuteTruncate(), to remove statistics entry of table.
--
Regards,
-------
Sawada Masahiko
Attachments:
Drop_statistics_after_truncated_v1.patchapplication/octet-stream; name=Drop_statistics_after_truncated_v1.patchDownload
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index ecdff1e..350a20d 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -1219,6 +1219,11 @@ ExecuteTruncate(TruncateStmt *stmt)
* Reconstruct the indexes to match, and we're done.
*/
reindex_relation(heap_relid, REINDEX_REL_PROCESS_TOAST);
+
+ /*
+ * Drop any pg_statistic entry of heap_relid
+ */
+ RemoveStatistics(heap_relid, 0);
}
}
Sawada Masahiko <sawada.mshk@gmail.com> writes:
I found that the statistics are still remained after it's truncated.
In addition, the analyzing ignores table does not have any tuple.
After table truncated, the entry of statistics continues to remain
unless insertion and analyzing are executed.
There is reason why statistics are remained?
Yes, actually, that's intentional. The idea is that once you start
loading data into the table, it's most likely going to look something
like the old data; therefore, the stale statistics are better than
none at all. Eventually auto-ANALYZE will replace the stats,
but until that happens, it seems best to keep using the old stats.
(Of course there are counterexamples to this, but removing the stats
is bad in more cases than not.)
Attached patch is one line patch adds RemoveStatistics() into
ExecuteTruncate(), to remove statistics entry of table.
-1, for the reasons explained above.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Oct 14, 2014 at 11:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Sawada Masahiko <sawada.mshk@gmail.com> writes:
I found that the statistics are still remained after it's truncated.
In addition, the analyzing ignores table does not have any tuple.
After table truncated, the entry of statistics continues to remain
unless insertion and analyzing are executed.
There is reason why statistics are remained?Yes, actually, that's intentional. The idea is that once you start
loading data into the table, it's most likely going to look something
like the old data; therefore, the stale statistics are better than
none at all. Eventually auto-ANALYZE will replace the stats,
but until that happens, it seems best to keep using the old stats.
(Of course there are counterexamples to this, but removing the stats
is bad in more cases than not.)Attached patch is one line patch adds RemoveStatistics() into
ExecuteTruncate(), to remove statistics entry of table.-1, for the reasons explained above.
I understood that reason.
Thank you for explaining!
--
Regards,
-------
Sawada Masahiko
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers