Re: RangeType internal use

Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
> On 02/09/2015 03:21 AM, Tom Lane wrote:
>> Meh. I don't care for that much --- it sounds a lot like deciding that
>> your problem is a nail because there is a hammer within reach. A random
>> collection of ranges doesn't seem like a very appropriate representation
>> to me; first because there is no simple way to enforce that it partitions
>> the key space (no overlaps and no missing portions), and second because it
>> provides little purchase for efficient tuple routing algorithms. The best
>> you could possibly hope for is some log-N tree search mechanism, and that
>> would require a fair amount of setup beforehand.

> Building a tree or a sorted array of the min or max bounds of the ranges
> doesn't sound hard. log-N sounds fast enough.

It's going to be complicated and probably buggy, and I think it is heading
in the wrong direction altogether. If you want to partition in some
arbitrary complicated fashion that the system can't reason about very
effectively, we *already have that*. IMO the entire point of building
a new partitioning infrastructure is to build something simple, reliable,
and a whole lot faster than what you can get from inheritance
relationships. And "faster" is going to come mainly from making the
partitioning rules as simple as possible, not as complex as possible.

Just to start with: one of the absolutely fundamental things we need out
of partitioning is the ability to have uniqueness constraints that span
a partitioned table set. That means the partitions have to be disjoint,
and it has to be not possible to break that. The design proposed here
won't enforce that without complicated (and again, possibly buggy) logic.

In short, this design requires a whole lot of extra mechanism to get to
places that we have to get to, and I don't believe that that extra
complexity is going to buy anything useful at all.

regards, tom lane