On Mon, Dec 8, 2014 at 2:30 PM, Josh Berkus <josh@agliodbs.com> wrote:
> On 12/08/2014 11:05 AM, Robert Haas wrote:
>> I guess I'm in disagreement with you - and, perhaps - the majority on
>> this point. I think that ship has already sailed: partitions ARE
>> tables. We can try to make it less necessary for users to ever look
>> at those tables as separate objects, and I think that's a good idea.
>> But trying to go from a system where partitions are tables, which is
>> what we have today, to a system where they are not seems like a bad
>> idea to me. If we make a major break from how things work today,
>> we're going to end up having to reimplement stuff that already works.
>
> 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?".
>> 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?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
