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's OK 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
