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

From Thomas Munro
Subject Re: VACUUM's ancillary tasks
Date
Msg-id CAEepm=1jASR6hz6ovUQHEXYuD9i4ssoq1nXsjtW6bgjxHuMB0w@mail.gmail.com
Whole thread
In response to VACUUM's ancillary tasks  (Vik Fearing <vik@2ndquadrant.fr>)
Responses Re: VACUUM's ancillary tasks
List pgsql-hackers
On Mon, Aug 29, 2016 at 1:26 PM, Vik Fearing <vik@2ndquadrant.fr> wrote:
> While doing this, I noticed that ALTER TABLE should also re-analyze the
> table for obvious reasons, so I have that one set
> "changes_since_analyze" to the number of rows rewritten as well.

I noticed that ATExecAlterColumnType does this:

    /*                                                                        
     * Drop any pg_statistic entry for the column, since it's now wrong type  
     */                                                                        
    RemoveStatistics(RelationGetRelid(rel), attnum);  

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?  Alternatively, we should consider bumping changes_since_analyze in this case too, if you're going to do it in the rewrite case.

--
Thomas Munro
http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Enrique Meneses
Date:
Subject: Re: Allowing GIN array_ops to work on anyarray
Next
From: Robert Haas
Date:
Subject: Re: store narrow values in hash indexes?