From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: yuzuko <yuzukohosoya@gmail.com>
Cc: David Steele <david@pgmasters.net>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>
Cc: Daniel Gustafsson <daniel@yesql.se>
Cc: Amit Langote <amitlangote09@gmail.com>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Greg Stark <stark@mit.edu>
Subject: Re: Autovacuum on partitioned table (autoanalyze)
Date: Sun, 4 Apr 2021 23:29:27 +0200
Message-ID: <a6d175e2-d906-ff89-2aed-a52e469474d3@enterprisedb.com> (raw)
In-Reply-To: <20210404200514.GA5220@alvherre.pgsql>
References: <20210404200514.GA5220@alvherre.pgsql>
On 4/4/21 10:05 PM, Alvaro Herrera wrote:
> On 2021-Apr-04, Tomas Vondra wrote:
>
>> 1) I still don't understand why inheritance and declarative partitioning
>> are treated differently. Seems unnecessary nad surprising, but maybe
>> there's a good reason?
>
> I suppose the rationale is that for inheritance we have always done it
> that way -- similar things have been done that way for inheritance
> historically, to avoid messing with long-standing behavior. We have
> done that in a bunch of places -- DDL behavior, FKs, etc. Maybe in this
> case it's not justified. It *will* change behavior, in the sense that
> we are going to capture stats that have never been captured before.
> That might or might not affect query plans for designs using regular
> inheritance. But it seems reasonable to think that those changes will
> be for the good; and if it does break plans for some people and they
> want to revert to the original behavior, they can just set
> autovacuum_enabled to off for the parent tables.
>
> So, I agree that we should enable this new feature for inheritance
> parents too.
>
Not sure. AFAICS the missing stats on parents are an issue both for
inheritance and partitioning. Maybe there is a reason to maintain the
current behavior with inheritance, but I don't see it.
With the other features, I think the reason for not implementing that
for inheritance was that it'd be more complex, compared to declarative
partitioning (which has stricter limitations on the partitions, etc.).
But in this case I think there's no difference in complexity, the same
code can handle both cases.
In fact, one of the first posts in this threads links to this:
https://www.postgresql.org/message-id/4823.1262132964%40sss.pgh.pa.us
i.e. Tom actually proposed doing something like this back in 2009, so
presumably he though it's desirable back then.
OTOH he argued against adding another per-table counter and proposed
essentially what the patch did before, i.e. propagating the counter
after analyze. But we know that may trigger analyze too often ...
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
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: tomas.vondra@enterprisedb.com, alvherre@alvh.no-ip.org, yuzukohosoya@gmail.com, david@pgmasters.net, horikyota.ntt@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: <a6d175e2-d906-ff89-2aed-a52e469474d3@enterprisedb.com>
* 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