Re: Table Partitioning Feature

Hi Emmanuel,

Please find my comments in-lined:

On 1/23/09, Emmanuel Cecchet <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
> Skype: emmanuel_cecchet
>
>