Re: Autovacuum on partitioned table (autoanalyze)

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Cc: yuzuko <yuzukohosoya(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Amit Langote <amitlangote09(at)gmail(dot)com>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Greg Stark <stark(at)mit(dot)edu>
Subject: Re: Autovacuum on partitioned table (autoanalyze)
Date: 2021-04-04 22:51:58
Message-ID: 20210404225158.GA22303@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2021-Apr-04, Tomas Vondra wrote:

> 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 ...

Yeah, I think that's a doomed approach. The reason to avoid another
column is to avoid bloat, which is good but if we end up with an
unworkable design then we know we have to backtrack on it.

I was thinking that we could get away with having a separate pgstat
struct for partitioned tables, to avoid enlarging the struct for all
tables, but if we're going to also include legacy inheritance in the
feature clearly that doesn't work.

--
Álvaro Herrera Valdivia, Chile
"After a quick R of TFM, all I can say is HOLY CR** THAT IS COOL! PostgreSQL was
amazing when I first started using it at 7.2, and I'm continually astounded by
learning new features and techniques made available by the continuing work of
the development team."
Berend Tober, http://archives.postgresql.org/pgsql-hackers/2007-08/msg01009.php

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2021-04-05 00:02:40 Re: pg_amcheck contrib application
Previous Message Tom Lane 2021-04-04 22:50:05 Re: ALTER TABLE ADD COLUMN fast default