On Tue, Sep 27, 2016 at 2:33 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@enterprisedb.com> writes:
>> I noticed that ATExecAlterColumnType does this:
>> * Drop any pg_statistic entry for the column, since it's now wrong type
>
>> What if there is no rewrite, because the type is binary compatible
>> (ATColumnChangeRequiresRewrite returns false)? Then I think your patch
>> won't attract an autovacuum daemon to ANALYZE the table and produce new
>> statistics, because it won't touch changes_since_analyze. I wonder if we
>> should simply keep the stats if no rewrite is required. Aren't the
>> statistical properties of binary-compatible types also compatible?
>
> Not necessarily: the type semantics might be different --- in fact,
> probably are different, else why would there be distinct types in the
> first place? It would be unwise to keep the old stats IMO.
>
> If you need a concrete example, consider OID vs int4. They're
> binary-compatible, but since int4 is signed while OID is unsigned,
> stats for one would be wrong for the other. This is the same reason
> why ALTER COLUMN TYPE has to rebuild indexes even in binary-compatible
> cases.
Ah, right. Then I think this patch should somehow bump
changes_since_analyze in the no-rewrite case if it's going to do it in
the rewrite case. It would be surprising and weird if altering a
column's type *sometimes* resulted in new statistics being
automatically generated to replace those that were dropped, depending
on the technical detail of whether a rewrite was necessary.
--
Thomas Munro
http://www.enterprisedb.com