On Wed, 2009-11-18 at 13:24 +0900, Itagaki Takahiro wrote:
> Simon Riggs <simon@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
