> > > It seems the way of specifying per-partition definition/constraint, > especially for range partitioning, would have a number of interesting > alternatives. > > By the way, the [USING opclass_name] bit is just a way of telling that a > particular key column has user-defined notion of "ordering" in case of > range partitioning and "equality" for list partitioning. The opclass would > eventually determine which WHERE clauses (looking at operators, operand > types) are candidates to help prune partitions. If we use the range_op > range_literal::range_type notation to describe partition constraint for > each partition, it might not offer much beyond the readability. We are not > really going to detect range operators being applied in WHERE conditions > to trigger partition pruning, for example. Although I may be missing > something... >
I don't think it's important that ranges be used internally for partition pruning, though I don't see a reason why they couldn't. I was making the case for range types being used at partition creation/declaration time, because you were proposing new syntax to describe a range of values in text when we already have that in range types. We should eat our own dog food. But mostly, I wanted to make sure that range partitions could have inclusive and exclusive bounds. > > > - No partitioning scheme survives first contact with reality. So you will > > need a facility for splitting and joining existing partitions. For > > splitting partitions, it's sufficient to require that the new partition > > share either a upper/lower bound (with the same inclusivity/exclusivity) > of > > an existing partition, thus uniquely identifying the partition to be > split, > > and require that the other bound be within the range of the partition to > be > > split. Similarly, it's fair to require that the partitions to be joined > be > > adjacent in range. In both cases, range operators make these tests > simple. > > > > SPLIT/MERGE can be done in later patches/release, I think. > Later patches for sure. When a partition "fills up", it's a critical performance issue, so the fewer steps needed to amend it the better.
