Re: Table Partitioning Feature

Hi Emmanuel,

On 1/26/09, Emmanuel Cecchet <manu(at)frogthinker(dot)org> wrote:
>
> 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?

We do intend to implement composite partitioning, but the delivery dates are
not yet decided.
I feel that simple forms of sub-partitioning can be realized using composite
partitioning, hence the implementation of sub-partitioning is not planned.

Thanks,
Amit

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
>
>