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
-
Describe (auto-)analyze behavior for partitioned tables
- 1b5617eb844c 14.0 landed
-
Add comment about extract_autovac_opts not holding lock
- 7c298c6573a0 14.0 landed
-
Set pg_class.reltuples for partitioned tables
- 0e69f705cc1a 14.0 landed
-
autovacuum: handle analyze for partitioned tables
- 0827e8af70f4 14.0 cited