Re: Autovacuum on partitioned table (autoanalyze) - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Autovacuum on partitioned table (autoanalyze)
Date
Msg-id 202108102138.rmo2pbphkkqs@alvherre.pgsql
Whole thread Raw
In response to Re: Autovacuum on partitioned table (autoanalyze)  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On 2021-Aug-10, Alvaro Herrera wrote:

> I bring a radical proposal that may be sufficient to close this
> particular hole.  What if we made partition only affected their
> top-level parents to become auto-analyzed, and not any intermediate
> ancestors?  Any intermediate partitioned partitions could be analyzed
> manually if the user wished, and perhaps some reloption could enable
> autovacuum to do it (with the caveat that it'd cause multiple sampling
> of partitions).  I don't yet have a clear picture on how to implement
> this, but I'll explore it while waiting for opinions on the idea.

So, with this patch (a quick and dirty job) we no longer sample all
partitions twice; we no longer propagate the tuple counts to p_0.
We don't have stats on p_0 anymore, only on p and on the individual
partitions.

I didn't move the new #include to a more decent place because
1. that stuff is going to move to partition.c as a new function,
including the new include;
2. that new function also needs to read the reloptions for p_0 to allow
the user to enable stat acquisition for p_0 with "alter table p_0 set
(autovacuum_enabled=1)";
3. need to avoid reporting ancestors of a partition repeatedly, which
forestalls the performance objection about reading reloptions too
frequently.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/

Attachment

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE
Next
From: "David G. Johnston"
Date:
Subject: Re: DROP relation IF EXISTS Docs and Tests - Bug Fix