DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=frogthinker.org;
	h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User;
	b=oLsE2YRySmpTTdBMvLWjhiW2St6SS0rIQyoUTpDxgGrWQELR+bf59CEvMcSikySGiVe+qir2H4XRa1jWNUXjQD8WBVYC74t1e/hGgzdIgjCOaw8bNcSN676F4L43ZRQA;
Message-ID: <49475519.9020000@frogthinker.org>
Date: Tue, 16 Dec 2008 02:13:29 -0500
From: Emmanuel Cecchet <manu@frogthinker.org>
Organization: Frog Thinker
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Nikhil Sontakke <nikhil.sontakke@enterprisedb.com>
CC: Jaime Casanova <jcasanov@systemguards.com.ec>,
	Gregory Stark <stark@enterprisedb.com>, Josh Berkus <josh@agliodbs.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Fwd: [PATCHES] Auto Partitioning Patch - WIP version
 1
References: <3073cc9b0810220744y987173avd560a33fcb58ede5@mail.gmail.com>	
	<3073cc9b0811270710p3a2e5ae9s10f66b529550c03e@mail.gmail.com>	
	<3073cc9b0811270712l6384c28awac4f0318c704df99@mail.gmail.com>	
	<492EC647.4090706@frogthinker.org>	
	<603c8f070812021452m65ed412ckc416e14b8e8f3f77@mail.gmail.com>	
	<493F1279.8010804@frogthinker.org> <49469894.4070406@agliodbs.com>	
	<87abaxp97w.fsf@oxford.xeocode.com>	
	<3073cc9b0812151101h3db74130xb5a808422e48c3f3@mail.gmail.com>	
	<49470CDC.7020707@frogthinker.org>
	<a301bfd90812152235j7af3bfabh5265c1e3ec813fd9@mail.gmail.com>
In-Reply-To: <a301bfd90812152235j7af3bfabh5265c1e3ec813fd9@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Nikhil Sontakke wrote:
> A similar DELETE trigger should be pretty easy to write up in C. I 
> think the main challenge is with UPDATE triggers especially if the new 
> row will fall into another child table - but we can always throw an 
> error for such a case initially.
I agree. A first implementation could be restricted to updates within 
the same partition.
>
>     Right now if the row cannot be inserted in any child table, it is
>     inserted in the parent. If you want to fail, we can add a 'fail
>     trigger' (after all other triggers) that generates an error if
>     previous triggers did not capture the row. If you want to create a
>     new partition, you can have another trigger to handle that.
>
>
> One of the work items related to partitioning eventually is to avoid 
> having to APPEND the parent in all queries involving children. Maybe 
> having an overflow child table might help to catch failed triggers for 
> those cases?
This is a good option too.

Emmanuel

>
> Regards,
> Nikhils
>  
>
>
>     So I think that this trigger approach is pretty flexible like
>     people used AOP in J2EE servers to process requests. It has also
>     the advantage of allowing fast prototyping. It should also be easy
>     to push that functionality down in the core as needed.
>
>     Is it ok if I move Simon's requirement document under a more
>     generic 'Table partitioning' page on the Wiki?
>
>     Thanks for your feedback,
>     manu
>
>
>     Jaime Casanova wrote:
>
>         On Mon, Dec 15, 2008 at 1:46 PM, Gregory Stark
>         <stark@enterprisedb.com <mailto:stark@enterprisedb.com>> wrote:
>          
>
>             Josh Berkus <josh@agliodbs.com <mailto:josh@agliodbs.com>>
>             writes:
>
>                
>
>                 Hackers,
>
>                 We don't yet seem to have a clear specification for
>                 this feature, and the Other
>                 Open Source DB has shown us how problematic it is to
>                 get auto-partitioning
>                 wrong.
>
>                 Should we defer auto-partitioning to 8.5?
>                      
>
>             If we're serious about having a "next generation"
>             partitioning with a concept
>             of partition keys then it seems to me to make more sense
>             to do that first and
>             then add on a feature like this.
>
>                
>
>
>         +1
>
>          
>
>             This is still very useful. I haven't looked at the actual
>             patch, does it
>             require core changes or can it be stashed in a pgfoundry
>             or contrib module?
>
>                
>
>
>         what i don't like about this one is that it creates partitions at
>         create table time and to manually add all new partitions (inherit
>         tables and modify the trigger)... and what i want to see is an
>         automatic creation when it's needed...
>