On Mon, Dec 8, 2014 at 2:58 PM, Josh Berkus <j...@agliodbs.com> wrote: >> 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.
I don't think it has to be possible to support every use case that we can support today; clearly, a part of the goal here is to be LESS general so that we can be more performant. But I think the urge to change too many things at once had better be tempered by a clear-eyed vision of what can reasonably be accomplished in one patch. -- 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
