On 02/09/2015 03:21 AM, Tom Lane wrote:
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.
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
