Re: Table Partitioning Feature - Mailing list pgsql-hackers

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@frogthinker.org 
> <mailto:manu@frogthinker.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@frogthinker.org <mailto:manu@frogthinker.org>
>     Skype: emmanuel_cecchet
>
>


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