From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Removing vacuum_cleanup_index_scale_factor |
Date: | 2021-03-09 06:21:13 |
Message-ID: | CAD21AoB6aCREW=5fHixuaLVFSNLpPSkBpdPTHFpeNwdWxXh5zA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 9, 2021 at 7:35 AM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> On Mon, Mar 8, 2021 at 1:38 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > As you say, the history here is a bit convoluted, but it seems like
> > a good principle to avoid interconnections between VACUUM and ANALYZE
> > as much as we can. I haven't been paying enough attention to this
> > thread to have more insight than that.
>
> The attached patch does what I proposed earlier today: it teaches
> do_analyze_rel() to always set pg_class.reltuples for indexes when it
> would do the same thing for the heap/table relation already. It's now
> uniform in that sense.
Thank you for the patches. I looked at 0001 patch and have a comment:
+ * We don't report to the stats collector here because the stats collector
+ * only tracks per-table stats. Reset the changes_since_analyze counter
+ * only if we analyzed all columns; otherwise, there is still work for
+ * auto-analyze to do.
I think the comment becomes clearer if we add "if doing inherited
stats" at top of the above paragraph since we actually report to the
stats collector in !inh case.
>
> Also included is a patch that removes the
> vacuum_cleanup_index_scale_factor mechanism for triggering an index
> scan during VACUUM -- that's what the second patch does (this depends
> on the first patch, really).
0002 patch looks good to me.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Joel Jacobson | 2021-03-09 06:34:36 | Re: [PATCH] pg_permissions |
Previous Message | vignesh C | 2021-03-09 06:10:33 | Re: [HACKERS] logical decoding of two-phase transactions |