Search Postgresql Archives

notes from transition to relkind='p'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux