Before I forget any more, this is a brain of issues/considerations/concerns
with our (partial) transition to partitioned tables over the last ~9 months. I
believe these are all documented behaviors, but could be seen by users as a
gratuitious/unexpected change or rough edge and the differences could perhaps
be mitigated. I realize there's maybe no good time or way to change most of
these, but maybe the list will be helpful to somebody in avoiding unexpected
transitional issues.
. DROP TABLE on a parent no longer fails without CASCADE (dependencies of
relkind='p' are deptype='a' "soft" dependencies)
8b4d582d279d784616c228be58af1e39aa430402
. ANALYZE relkind_p also updates stats of child (whereas ANALYZE relkind_r
only updates stats for parent); it's unclear if there's any reason why it
wasn't always done this way(?). I end up having to conditionize processing
based on relkind. 3c3bb99330aa9b4c2f6258bfa0265d806bf365c3
. The docs say: if detaching/re-attach a partition, should first ADD CHECK to
avoid a slow ATTACH operation. Perhaps DETACHing a partition could
implicitly CREATE a constraint which is usable when reATTACHing?
. relkind_p has no entry in pg_stat_user_tables (last_analyze, etc). Maybe
the view could do the needed CASE ... (SELECT min() FROM pg_inherits JOIN psut)
. ALTER TABLE ATTACH requires specifying bounds: Maybe it sounds naive to
suggest one would want to avoid that; but consider: we ended up adding both
shell and python logic to parse the table name to allow detaching and
reattaching partitions. I think it'd be a nice if the bounds were inferred
if there was a single constraint on the partition key.
. ALTER TABLE ATTACH has reversed order of child vs parent relative to
NO/INHERIT.
. And actually, having both ALTER TABLE DE/TACH vs NO/INHERIT is itself messy:
we ended up having branches (both shell and python) to handle both cases (at
least for a transitional period, but probably we'll need to continue
handling both into the indeterminate future).
Cheers,
Justin
