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.
> 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.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
