Date: Fri, 9 Apr 2021 18:16:59 -0400
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>
Subject: Re: pgsql: autovacuum: handle analyze for partitioned tables
Message-ID: <20210409221659.GA28298@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20210409214508.GV6592@telsasoft.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: 
 <https://www.postgresql.org/message-id/20210409221659.GA28298%40alvherre.pgsql>
Precedence: bulk

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)