Hi Emmanuel,
On 1/26/09, Emmanuel Cecchet <m...@frogthinker.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* <m...@frogthinker.org <mailto: >> m...@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: m...@frogthinker.org <mailto:m...@frogthinker.org> >> Skype: emmanuel_cecchet >> >> >> > > -- > Emmanuel Cecchet > FTO @ Frog Thinker Open Source Development & Consulting > -- > Web: http://www.frogthinker.org > email: m...@frogthinker.org > Skype: emmanuel_cecchet > >
