On 02/09/2015 03:21 AM, Tom Lane wrote:
> Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes:
>> On 07-02-2015 AM 12:10, Tom Lane wrote:
>>> There is no good reason to assume that a range type exists at all, much
>>> less that it is unique for a subtype. (Read the CREATE TYPE documentation
>>> if you're unclear as to why not.) You have not said what you're trying to
>>> accomplish, but this seems like a dead end.
>
>> Sorry I didn't mention before about an idea I am trying to implement
>> with this - it is to serialize range partition bounds as a range type
>> value per partition key column. The serialized representation of a range
>> partition bound for a partition then effectively becomes an anyarray of
>> anyrange:
>
> 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.
> I'd rather insist that range partitioning be done on the basis of an
> origin point and a bin width, which would allow trivial computation of
> which bin number any given key falls in. This will limit the set of types
> it can be done over, for sure, but not more than depending on built-in
> range types would.
That sounds unnecessarily limiting. If there's a good reason to limit it
to that, then fine, but I don't think it'd be any more difficult to make
it flexible. Let's wait for the patch and see I guess.
- Heikki