Re: RangeType internal use

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RangeType internal use
Date: 2015-02-09 17:37:05
Message-ID: 28417.1423503425@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Feb 9, 2015 at 10:36 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.

> Yeah, but people expect to be able to partition on ranges that are not
> all of equal width. I think any proposal that we shouldn't support
> that is the kiss of death for a feature like this - it will be so
> restricted as to eliminate 75% of the use cases.

Well, that's debatable IMO (especially your claim that variable-size
partitions would be needed by a majority of users). But in any case,
partitioning behavior that is emergent from a bunch of independent pieces
of information scattered among N tables seems absolutely untenable from
where I sit. Whatever we support, the behavior needs to be described by
*one* chunk of information --- a sorted list of bin bounding values,
perhaps.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-02-09 17:38:07 Re: RangeType internal use
Previous Message Robert Haas 2015-02-09 17:32:08 Re: RangeType internal use