Amit Langote <langote_amit...@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.
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
