On Wed, 2009-11-18 at 13:24 +0900, Itagaki Takahiro wrote: > Simon Riggs <si...@2ndquadrant.com> wrote: > > > Why not just wait until we have a whole patch and then apply? > > "A whole patch" can be written by many contributers instead of only > one person, no? I think we need to split works for partitioning > into serveral parts to encourage developing it. I just did one of > the parts, "syntax". Anothe patch "Partitioning option for COPY" > will do a good job in the field of "INSERT".
If we can agree the parts that are required, I would at least be confident that we have understood this enough to allow one part to proceed ahead of the others. For partitioning the parts are these 1. Syntax for explicit partitioning 2. Internal data representations 3. Optimizations many and various 4. Data Routing a) Data routing on INSERT/COPY b) UPDATE handling when the UPDATE causes partition migration If this patch puts forward a solution for (2) also, then it is potentially worthwhile. That is the real blocking point here. Once we have that other people will quickly fill in the later parts. I foresee a data structure that is a sorted list of boundary-values, cached on the parent-relation. This should be accessible to allow bsearch of particular values during both planning and execution. Same rules apply as btree operator classes. For multi-level hierarchies the parent level should have the union of all sub-hierarchies. I think we need an index on pg_inherits also. So please do (1) and (2), not just (1) in isolation. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
