Re: Drop any statistics of table after it's truncated

From: Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Drop any statistics of table after it's truncated
Date: 2014-10-14 15:16:28
Message-ID: CAD21AoC++RtZA8_Tve7MB62_XxmX3jckzWVTiLQeeucLOSbigQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 14, 2014 at 11:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-10-14 15:19:16 Re: WIP: dynahash replacement for buffer table
Previous Message Amit Kapila 2014-10-14 15:10:19 Re: WIP: dynahash replacement for buffer table