> From: Stephen Frost [mailto:sfr...@snowman.net] > Sent: Thursday, November 13, 2014 3:40 PM > > > 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. > > I agree that these will require different structures in the catalog.. > While reviewing the superuser checks, I expected to have a similar need > and discussed various options- having multiple catalog tables, having a > single table with multiple columns, having a single table with a 'type' > column and then a bytea blob. In the end, it wasn't really necessary as > the only thing which I expected to need more than 'yes/no' were the > directory permissions (which it looks like might end up killed anyway, > much to my sadness..), but while considering the options, I continued to > feel like anything but independent tables was hacking around to try and > reduce the number of inodes used for folks who don't actually use these > features, and that's a terrible reason to complicate the catalog and > code, in my view. >
Greenplum uses a single table for this purpose with separate columns for range and list cases, for example. They store allowed values per partition though. They have 6 partitioning related catalog/system views., by the way. Perhaps, interesting as a reference. http://gpdb.docs.pivotal.io/4330/index.html#ref_guide/system_catalogs/pg_parti tions.html Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
