From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: yuzukohosoya@gmail.com
Cc: pryzby@telsasoft.com
Cc: daniel@yesql.se
Cc: amitlangote09@gmail.com
Cc: masahiko.sawada@2ndquadrant.com
Cc: laurenz.albe@cybertec.at
Cc: pgsql-hackers@lists.postgresql.org
Cc: stark@mit.edu
Subject: Re: Autovacuum on partitioned table (autoanalyze)
Date: Mon, 30 Nov 2020 14:57:09 -0300
Message-ID: <20201130175709.GA30970@alvherre.pgsql> (raw)
In-Reply-To: <20201110.203557.1420746510378864931.horikyota.ntt@gmail.com>
On 2020-Nov-10, Kyotaro Horiguchi wrote:
> In second thought about the reason for the "toprel_oid". It is perhaps
> to avoid "wrongly" propagated values to ancestors after a manual
> ANALYZE on a partitioned table. But the same happens after an
> autoanalyze iteration if some of the ancestors of a leaf relation are
> analyzed before the leaf relation in a autoanalyze iteration. That
> can trigger an unnecessary analyzing for some of the ancestors.
I'm not sure I understand this point. I think we should only trigger
this on analyzes of *leaf* partitions, not intermediate partitioned
relations. That way you would never get these unnecesary analyzes.
Am I missing something?
(So with my proposal in the previous email, we would send the list of
ancestor relations after analyzing a leaf partition. Whenever we
analyze a non-leaf, then the list of ancestors is sent as an empty
list.)
> > > Regarding the counters in pg_stat_all_tables: maybe some of these should be
> > > null rather than zero ? Or else you should make an 0001 patch to fully
> > > implement this view, with all relevant counters, not just n_mod_since_analyze,
> > > last_*analyze, and *analyze_count. These are specifically misleading:
> > >
> > > last_vacuum |
> > > last_autovacuum |
> > > n_ins_since_vacuum | 0
> > > vacuum_count | 0
> > > autovacuum_count | 0
> > >
> > I haven't modified this part yet, but you meant that we should set
> > null to counters
> > about vacuum because partitioned tables are not vacuumed?
>
> Perhaps bacause partitioned tables *cannot* be vacuumed. I'm not sure
> what is the best way here. Showing null seems reasonable but I'm not
> sure that doesn't break anything.
I agree that showing NULLs for the vacuum columns is better. Perhaps
the most reasonable way to do this is use -1 as an indicator that NULL
ought to be returned from pg_stat_get_vacuum_count() et al, and add a
boolean in PgStat_TableCounts next to t_truncated, maybe "t_nullvacuum"
that says to store -1 instead of 0 in pgstat_recv_tabstat.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: alvherre@alvh.no-ip.org, horikyota.ntt@gmail.com, yuzukohosoya@gmail.com, pryzby@telsasoft.com, daniel@yesql.se, amitlangote09@gmail.com, masahiko.sawada@2ndquadrant.com, laurenz.albe@cybertec.at, pgsql-hackers@lists.postgresql.org, stark@mit.edu
Subject: Re: Autovacuum on partitioned table (autoanalyze)
In-Reply-To: <20201130175709.GA30970@alvherre.pgsql>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox