Re: On partitioning

On 12/08/2014 11:40 AM, Robert Haas wrote:
>> I don't thing its feasible to drop inheritance partitioning at this
>> point; too many user exploit a lot of peculiarities of that system which
>> wouldn't be supported by any other system. So any new partitioning
>> system we're talking about would be *in addition* to the existing
>> system. Hence my prior email trying to make sure that a new proposed
>> system is sufficiently different from the existing one to be worthwhile.
>
> I think any new partitioning system should keep the good things about
> the existing system, of which there are some, and not try to reinvent
> the wheel. The yard stick for a new system shouldn't be "is this
> different enough?" but "does this solve the problems without creating
> new ones?".

It's unrealistic to assume that a new system would support all of the
features of the existing inheritance partitioning without restriction.
In fact, I'd say that such a requirement amounts to saying "don't
bother trying".

For example, inheritance allows us to have different indexes,
constraints, and even columns on partitions. We can have overlapping
partitions, and heterogenous multilevel partitioning (partition this
customer by month but partition that customer by week). We can even add
triggers on individual partitions to reroute data away from a specific
partition. A requirement to support all of these peculiar uses of
inheritance partitioning would doom any new partitioning project.

>>> Besides, I haven't really seen anyone propose something that sounds
>>> like a credible alternative. If we could make partition objects
>>> things that the storage layer needs to know about but the query
>>> planner doesn't need to understand, that'd be maybe worth considering.
>>> But I don't see any way that that's remotely feasible.
>>
>> On the other hand, as long as partitions exist exclusively at the
>> planner layer, we can't fix the existing major shortcomings of
>> inheritance partitioning, such as its inability to handle expressions.
>> Again, see previous.
>
> Huh?

Explained in the other email I posted on this thread.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com