On Mon, Apr 24, 2017 at 6:43 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > The reason it doesn't work is that we do not allocate ResultRelInfos for > partitioned tables (not even for the root partitioned table in the > update/delete cases), because the current implementation assumes they are > not required. That's fine only so long as we consider that no rows are > inserted into them, no indexes need to be updated, and that no row-level > triggers are to be fired. But it misses the fact that we do allow > statement-level triggers on partitioned tables. So, we should fix things > such that ResultRelInfos are allocated so that any statement-level > triggers are fired. But there are following questions to consider: > > 1. Should we consider only the root partitioned table or all partitioned > tables in a given hierarchy, including the child partitioned tables? > Note that this is related to a current limitation of updating/deleting > inheritance hierarchies that we do not currently fire per-statement > triggers of the child tables. See the TODO item in wiki: > https://wiki.postgresql.org/wiki/Todo#Triggers, which says: "When > statement-level triggers are defined on a parent table, have them fire > only on the parent table, and fire child table triggers only where > appropriate" > > 2. Do we apply the same to inserts on the partitioned tables? Since > insert on a partitioned table implicitly affects its partitions, one > might say that we would need to fire per-statement insert triggers of > all the partitions.
It seems to me that it doesn't make a lot of sense to fire the triggers for some tables involved in the hierarchy and not others. I suppose the consistent thing to do here is to make sure that we fire the statement triggers for all tables in the partitioning hierarchy for all operations (insert, update, delete, etc.). TBH, I don't like that very much. I'd rather fire the triggers only for the table actually named in the query and skip all the others, mostly because it seems like it would be faster and less likely to block future optimizations; eventually, I'd like to consider not even locking the children we're not touching, but that's not going to work if we have to check them all for triggers. So what I'd prefer -- on the totally unprincipled basis that it would let us improve performance in the future -- if you operate on a partition directly, you fire the partition's triggers, but if you operate on the parent, only the parent's triggers fire. How heretical is that idea? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
