Re: pgsql: autovacuum: handle analyze for partitioned tables

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

From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Justin Pryzby <pryzby@telsasoft.com>
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-09T22:16:59Z
Lists: pgsql-hackers
On 2021-Apr-09, Justin Pryzby wrote:

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

You mean to trigger an ANALYZE, not to trigger an ALTER, right?

I think I agree with Tomas: we should do it by default, and offer some
way to turn that off.  I suppose a new reloptions, solely for
partitioned tables, would be the way to do it.

> However, I think DROP should be handled ?

DROP of a partition? ... I would think it should do the same as DETACH,
right?  Inform that however many rows the partition had, are now changed
in ancestors.

-- 
Álvaro Herrera                            39°49'30"S 73°17'W
"Aprender sin pensar es inútil; pensar sin aprender, peligroso" (Confucio)



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