On Wed, Nov 12, 2014 at 5:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> I thought putting the partition boundaries into pg_inherits was a
>> strange choice. I'd put it in pg_class, or in pg_partition if we
>> decide to create that.
>
> Yeah. I rather doubt that we want this mechanism to be very closely
> tied to the existing inheritance features. If we do that, we are
> going to need a boatload of error checks to prevent people from breaking
> partitioned tables by applying the sort of twiddling that inheritance
> allows.
Well, as I said upthread, I think it would be a pretty poor idea to
imagine that the first version of this feature is going to obsolete
everything we've done with inheritance. Are we going to reinvent the
machinery to make inheritance children get scanned when the parent
does? Reinvent Merge Append?
>> Maybe as anyarray, but I think pg_node_tree
>> might even be better. That can also represent data of some arbitrary
>> type, but it doesn't enforce that everything is uniform.
>
> Of course, the more general you make it, the more likely that it'll be
> impossible to optimize well.
The point for me is just that range and list partitioning probably
need different structure, and hash partitioning, if we want to support
that, needs something else again. Range partitioning needs an array
of partition boundaries and an array of child OIDs. List partitioning
needs an array of specific values and a child table OID for each.
Hash partitioning needs something probably quite different. We might
be able to do it as a pair of arrays - one of type anyarray and one of
type OID - and meet all needs that way.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
