From: | "Amit Langote" <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | "'Jim Nasby'" <Jim(dot)Nasby(at)BlueTreble(dot)com>, "'Robert Haas'" <robertmhaas(at)gmail(dot)com> |
Cc: | "'Andres Freund'" <andres(at)2ndquadrant(dot)com>, "'Alvaro Herrera'" <alvherre(at)2ndquadrant(dot)com>, "'Bruce Momjian'" <bruce(at)momjian(dot)us>, "'Pg Hackers'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: On partitioning |
Date: | 2014-12-04 05:16:28 |
Message-ID: | 01ca01d00f81$74f2c750$5ed855f0$@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
> Something else to consider... our user-space support for ranges is now
> rangetypes, so perhaps that's what we should use for range partitioning. The
> up-side (which would be a double-edged sword) is that you could leave holes
> in your partitioning map. Note that in the multi-key case we could still have a
> record of rangetypes.
That is something I had mind at least at some point. My general doubt remains about the usage of user space SQL types for catalog fields though I may be completely uninitiated about such usage.
Thanks,
Amit
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2014-12-04 06:35:18 | Parallel Seq Scan |
Previous Message | Ashutosh Bapat | 2014-12-04 04:48:20 | Re: inherit support for foreign tables |