On Tue, Sep 27, 2016 at 2:33 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Thomas Munro <thomas.mu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
