Re: VACUUM's ancillary tasks - Mailing list pgsql-hackers

From Tom Lane
Subject Re: VACUUM's ancillary tasks
Date
Msg-id 29335.1474896811@sss.pgh.pa.us
Whole thread Raw
In response to Re: VACUUM's ancillary tasks  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: VACUUM's ancillary tasks  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Allowing GIN array_ops to work on anyarray
Next
From: Magnus Hagander
Date:
Subject: Small race in pg_xlogdump --follow