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