Re: Partitioning option for COPY

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

In response to

Responses

Browse pgsql-hackers by date

  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