> From: Stephen Frost [mailto:sfrost@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
