Re: Autovacuum on partitioned table (autoanalyze)

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