Horton

Re: Autovacuum on partitioned table (autoanalyze)

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Andres Freund <andres@anarazel.de>
Cc: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, yuzuko <yuzukohosoya@gmail.com>, Tomas Vondra <tomas.vondra@enterprisedb.com>, David Steele <david@pgmasters.net>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>, Daniel Gustafsson <daniel@yesql.se>, Amit Langote <amitlangote09@gmail.com>, Masahiko Sawada <masahiko.sawada@2ndquadrant.com>, Laurenz Albe <laurenz.albe@cybertec.at>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Greg Stark <stark@mit.edu>
Date: 2021-08-10T13:27:33Z
Lists: pgsql-hackers 
On 2021-Aug-09, Andres Freund wrote:

> I don't agree. There's a difference between this happening after a manual
> ANALYZE on partition roots, and this continuously happening in production
> workloads due to auto-analyzes...

Hmm.  That's not completely untrue.

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.

-- 
Álvaro Herrera              Valdivia, Chile  —  https://www.EnterpriseDB.com/
"Nadie está tan esclavizado como el que se cree libre no siéndolo" (Goethe)

Commits

  1. Keep stats up to date for partitioned tables

  2. Revert analyze support for partitioned tables

  3. Document ANALYZE storage parameters for partitioned tables

  4. autovacuum: handle analyze for partitioned tables