Re: On partitioning

On Thu, Dec 4, 2014 at 10:46 AM, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
wrote:
>
>
> Hi,
>
> > From: Jim Nasby [mailto:Jim(dot)Nasby(at)BlueTreble(dot)com]
> > On 12/2/14, 9:43 PM, Amit Langote wrote:
> >
> > >> >What are you going to do if the partitioning key has two columns of
> > >> >different data types?
> > >> >
> > > Sorry, this totally eluded me. Perhaps, the 'values' needs some more
thought.
> > They are one of the most crucial elements of the scheme.
> > >
> > > I wonder if your suggestion of pg_node_tree plays well here. This
then could
> > be a list of CONSTs or some such... And I am thinking it's a concern
only for
> > range partitions, no? (that is, a multicolumn partition key)
> > >
> > > I think partkind switches the interpretation of the field as
appropriate. Am I
> > missing something? By the way, I had mentioned we could have two values
> > fields each for range and list partition kind.
> >
> > 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);

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com