Re: On partitioning

From: Amit Kapila [mailto:amit(dot)kapila16(at)gmail(dot)com]
On Fri, Dec 5, 2014 at 12:27 PM, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> From: Amit Kapila [mailto:amit(dot)kapila16(at)gmail(dot)com]
> On Thu, Dec 4, 2014 at 10:46 AM, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> >
> > > The more SQL way would be records (composite types). That would make
> > > catalog inspection a LOT easier and presumably make it easier to change the
> > > partitioning key (I'm assuming ALTER TYPE cascades to stored data). Records
> > > are stored internally as tuples; not sure if that would be faster than a List of
> > > Consts or a pg_node_tree. Nodes would theoretically allow using things other
> > > than Consts, but I suspect that would be a bad idea.
> > >
> >
> > While I couldn’t find an example in system catalogs where a record/composite type is used, there are instances of pg_node_tree at a number of places like in pg_attrdef and others. Could you please point me to such a usage for reference?
> >
>
> > I think you can check the same by manually creating table
> > with a user-defined type.
>
> > Create type typ as (f1 int, f2 text);
> > Create table part_tab(c1 int, c2 typ);
>
> Is there such a custom-defined type used in some system catalog? Just not sure how one would put together a custom type to use in a system catalog given the way a system catalog is created. That's my concern but it may not be valid.
>

> I think you are right. I think in this case we need something similar
> to column pg_index.indexprs which is of type pg_node_tree(which
> seems to be already suggested by Robert). So may be we can proceed
> with this type and see if any one else has better idea.

Yeah, with that, I was thinking we may be able to do something like dump a Node that describes the range partition bounds or list of allowed values (say, RangePartitionValues, ListPartitionValues).

Thanks,
Amit