From: Amit Kapila [mailto:amit.kapila16@gmail.com]
Sent: Friday, December 05, 2014 5:10 PM
To: Amit Langote
Cc: Jim Nasby; Robert Haas; Andres Freund; Alvaro Herrera; Bruce Momjian; Pg Hackers
Subject: Re: [HACKERS] On partitioning
On Fri, Dec 5, 2014 at 12:27 PM, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote:
> From: Amit Kapila [mailto:amit.kapila16@gmail.com]
> On Thu, Dec 4, 2014 at 10:46 AM, Amit Langote <Langote_Amit_f8@lab.ntt.co.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_treeat 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
typeto 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.
One point raised about/against pg_node_tree was the values represented therein would turn out to be too generalized to
beused with advantage during planning. But, it seems we could deserialize it in advance back to the internal form (like
anarray of a struct) as part of the cached relation data. This overhead would only be incurred in case of partitioned
tables.Perhaps this is what Robert suggested elsewhere.
Thanks,
Amit
