On Mon, Nov 10, 2014 at 8:53 PM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> Above commands are merely transformed into ALTER TABLE subcommands that arrange
> partitioned table and partitions into inheritance hierarchy, but with extra
> information, that is, allowed values for the partition in a new anyarray column
> called 'pg_inherits.values'. A special case of ATExecAddInherit() namely
> ATExecAttachPartitionI(), as part of its processing, also adds partition
> constraints in the form of appropriate CHECK constraints. So, a few of the
> manual steps are automated and additional (IMHO non-opaque) metadata (namely
> partition boundaries/list values) is added.
I thought putting the partition boundaries into pg_inherits was a
strange choice. I'd put it in pg_class, or in pg_partition if we
decide to create that. 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. So you could
have a list of objects of the form {RANGEPARTITION :lessthan {CONST
...} :partition 16982} or similar. The relcache could load that up
and convert the list to a C array, which would then be easy to
binary-search.
As you say, you also need to store the relevant operator somewhere,
and the fact that it's a range partition rather than list or hash,
say.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
