Re: Table Partitioning Feature

Hi Amit,

I overlooked the fact that you dropped composite partitions and
subpartitions template from the proposal presented in
http://archives.postgresql.org/pgsql-hackers/2008-01/msg00413.php.
Is it because this is too hard to support? or you don't see any
immediate need for it?

Thanks,
Emmanuel

> Hi Emmanuel,
>
> Please find my comments in-lined:
>
> On 1/23/09, *Emmanuel Cecchet* <manu(at)frogthinker(dot)org
> <mailto:manu(at)frogthinker(dot)org>> wrote:
>
> Amit,
>
> You might want to put this on the
> http://wiki.postgresql.org/wiki/Table_partitioning wiki page.
>
>
> Sure.
>
> How does your timeline look like for this implementation?
>
>
> The implementation is planned as follows:
> - Partition table commands
> ++ An intermediate patch in Feb end
> ++ Final patch in mid March
> - Global Index: Mid March
> - Optimizer changes for partitioned table: May
>
> I would be happy to contribute C triggers to your implementation.
> From what I understood in
> http://archives.postgresql.org/pgsql-hackers/2008-01/msg00269.php,
> you already have an implementation that parses the grammar and
> generates rules as if someone had written them. Is this code
> available?
>
>
> We have just started with the implementation, i will post the grammar
> rules next week.
>
>
> Regarding the use of triggers to push/move data to partitions,
> what if someone declares triggers on partitions? Especially if you
> have subpartitions, let's consider the case where there is a
> trigger on the parent, child and grandchild. If I do an insert in
> the parent, the user trigger on the parent will be executed, then
> the partition trigger that decides to move to the grandchild. Are
> we going to bypass the child trigger?
>
>
> We are not supporting sub-partitioning - There is just one level of
> partitioning.
>
> If we also want fast COPY operations on partitioned table, we
> could have an optimized implementation that could bypass triggers
> and move the tuple directly to the appropriate child table.
>
>
> We will definitely consider to implement fast COPY after we are done
> with the planned tasks.
>
> Thanks,
> Amit
>
>
> Thanks for this big contribution,
> Emmanuel
>
> Hi,
>
> We are implementing table partitioning feature to support
> - the attached commands. The syntax conforms to most of the
> suggestion mentioned in
> http://archives.postgresql.org/pgsql-hackers/2008-01/msg00413.php,
> barring the following:
> -- Specification of partition names is optional. System will
> be able to generate partition names in such cases.
> -- sub partitioning
> We are using pgsql triggers to push/move data to appropriate
> partitions, but we will definitely consider moving to C
> language triggers as suggested by manu.
> - Global non-partitioned indexes (that will extend all the
> partitions).
> - Foreign key support for tables referring to partitioned tables.
>
> Please feel free to post your comments and suggestions.
>
> Thanks,
> Amit
> Persistent Systems
>
>
>
> ------------------------------------------------------------------------
>
>
>
>
> --
> Emmanuel Cecchet
> FTO @ Frog Thinker Open Source Development & Consulting
> --
> Web: http://www.frogthinker.org
> email: manu(at)frogthinker(dot)org <mailto:manu(at)frogthinker(dot)org>
> Skype: emmanuel_cecchet
>
>

--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: manu(at)frogthinker(dot)org
Skype: emmanuel_cecchet