On Fri, Apr 09, 2021 at 06:16:59PM -0400, Alvaro Herrera wrote: > 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?
Oops, right. It's slightly undesirable for a DETACH to cause an ANALYZE. > 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. Yes, drop of an (attached) partition. The case for DROP is clear, since it was clearly meant to go away forever. The case for DETACH seems somewhat less clear. The current behavior of pg_dump/restore (since 33a53130a) is to CREATE+ATTACH, so there's an argument that if DROPping the partition counts towards the parent's analyze, then so should CREATE+ATTACH. -- Justin
