From: Emmanuel Cecchet <manu@frogthinker.org>
To: Nikhil Sontakke <nikhil.sontakke@enterprisedb.com>
Cc: Jaime Casanova <jcasanov@systemguards.com.ec>
Cc: Gregory Stark <stark@enterprisedb.com>
Cc: Josh Berkus <josh@agliodbs.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1
Date: Tue, 16 Dec 2008 02:13:29 -0500
Message-ID: <49475519.9020000@frogthinker.org> (raw)
In-Reply-To: <a301bfd90812152235j7af3bfabh5265c1e3ec813fd9@mail.gmail.com>
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>
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...
>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-patches@postgresql.org
Cc: manu@frogthinker.org, nikhil.sontakke@enterprisedb.com, jcasanov@systemguards.com.ec, stark@enterprisedb.com, josh@agliodbs.com, pgsql-hackers@postgresql.org
Subject: Re: Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1
In-Reply-To: <49475519.9020000@frogthinker.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox