On 11/12/14, 5:27 PM, Robert Haas wrote:
>>> 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.
Another issue is I don't know that we could support multi-key partitions with something like an anyarray. Perhaps
that'sOK as a first pass, but I expect it'll be one of the next things folks ask for.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com