Horton

Re: pgsql: autovacuum: handle analyze for partitioned tables

Justin Pryzby <pryzby@telsasoft.com>

View thread View on postgr.es
From: Justin Pryzby <pryzby@telsasoft.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Zhihong Yu <zyu@yugabyte.com>, pgsql-hackers@lists.postgresql.org, Yuzuko <yuzukohosoya@gmail.com>
Date: 2021-04-09T21:45:08Z
Lists: pgsql-hackers 
On Fri, Apr 09, 2021 at 05:31:55PM -0400, Alvaro Herrera wrote:
> On 2021-Apr-09, Robert Haas wrote:
> 
> > Does this need to worry about new partitions getting attached to a
> > partitioned table, or old ones getting detached? (Maybe it does
> > already, not sure.)
> 
> Good question.  It does not.

I think there's probably cases where this is desirable, and cases where it's
undesirable, so I don't think it's necessarily a problem.

One data point: we do DETACH/ATTACH tables during normal operation, before
type-promoting ALTERs, to avoid worst-case disk use, and to avoid locking the
table for a long time.  It'd be undesirable (but maybe of no great consequence)
to trigger an ALTER when we DETACH them, since we'll re-ATTACH it shortly
afterwards.

However, I think DROP should be handled ?

-- 
Justin

Commits

  1. Describe (auto-)analyze behavior for partitioned tables

  2. Add comment about extract_autovac_opts not holding lock

  3. Set pg_class.reltuples for partitioned tables

  4. autovacuum: handle analyze for partitioned tables