Re: RangeType internal use

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RangeType internal use
Date: 2015-02-09 01:21:10
Message-ID: 12417.1423444870@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2015-02-09 05:54:49 Re: pgbench -f and vacuum
Previous Message David Steele 2015-02-09 01:02:41 Re: pgaudit - an auditing extension for PostgreSQL