Horton

Re: On partitioning

Jim Nasby <jim.nasby@bluetreble.com>

View thread View on postgr.es
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
To: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, Andres Freund <andres@2ndquadrant.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Bruce Momjian <bruce@momjian.us>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-11-12T23:31:48Z
Lists: pgsql-hackers 
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