Re: VACUUM's ancillary tasks

Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)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.

regards, tom lane