From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Vik Fearing <vik(at)2ndquadrant(dot)fr> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: VACUUM's ancillary tasks |
Date: | 2016-09-26 01:05:37 |
Message-ID: | CAEepm=1jASR6hz6ovUQHEXYuD9i4ssoq1nXsjtW6bgjxHuMB0w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 29, 2016 at 1:26 PM, Vik Fearing <vik(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-09-26 01:51:51 | Re: store narrow values in hash indexes? |
Previous Message | Enrique Meneses | 2016-09-26 00:59:05 | Re: Allowing GIN array_ops to work on anyarray |