From: | Emmanuel Cecchet <manu(at)asterdata(dot)com> |
---|---|
To: | Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
Cc: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com>, Emmanuel Cecchet <manu(at)asterdata(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Emmanuel Cecchet <Emmanuel(dot)Cecchet(at)asterdata(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Partitioning option for COPY |
Date: | 2009-11-24 15:08:33 |
Message-ID: | 4B0BF6F1.8050300@asterdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Itagaki Takahiro wrote:
> I just edited a wiki page for this discussion.
> I hope it can be a help.
> http://wiki.postgresql.org/wiki/Table_partitioning
>
I guess the problem of handling user triggers is still open.
If we allow triggers on partitions, badly written logic could lead to
infinite loops in routing. In the case of COPY, an after statement
trigger could change all the routing decisions taken for each row. I am
not sure what the semantic should be if you have triggers defined on the
parent and child tables. Which triggers do you fire if the insert is on
the parent table but the tuple ends up in a child table?
If the new implementation hides the child tables, it might be safer to
not allow triggers on child tables altogether and use the parent table
as the single point of entry to access the partition (and define
triggers). With the current proposed implementation, would it be
possible to define a view using child tables?
Emmanuel
--
Emmanuel Cecchet
Aster Data
Web: http://www.asterdata.com
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Meskes | 2009-11-24 15:44:04 | Re: ecpg & 8.3 -> 8.4 migration |
Previous Message | Robert Haas | 2009-11-24 14:56:28 | Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION |