Re: FK violation in partitioned table after truncating a referencedpartition
От | Jehan-Guillaume de Rorthais |
---|---|
Тема | Re: FK violation in partitioned table after truncating a referencedpartition |
Дата | |
Msg-id | 20200207230314.350a59bc@firost обсуждение исходный текст |
Ответ на | Re: FK violation in partitioned table after truncating a referencedpartition (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | pgsql-bugs |
On Fri, 7 Feb 2020 17:19:48 -0300 Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > There's another key point I forgot -- which is that we only need to > search for constraints on the topmost partitioned table, not each of its > partitions. The reason is that pg_constraint rows exist on the other > side that reference that relation, for each partition on the other side. Yes, I figured this as well when drawing things during debug time. By this time, I kept it this way because I wasn't sure about potential complications with sub-partitioning and FK to sub-partition only. > So we can do this: [...] > that is, keep appending to the parent_cons list, and not touch the oids > list, until we get to the top of the hierarchy. Then when we redo the > first loop, we'll get all partitions on the other side because they all > have pg_constraint rows that reference the topmost rel. (That is to > say, all the intermediate-partition OIDs should be useless in the 'oids' > list anyway.) It makes the oids list smaller (depending on the partitioning depth). As it is scanned for each FK in pg_constraint, it surely squeeze some more time. I'll stick around irw the other FK violation thread. Please, keep me in the loop. Thank you for the discussion and commit. Regards,
В списке pgsql-bugs по дате отправления: