On Mon, Dec 8, 2014 at 2:30 PM, Josh Berkus <j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
