Hi, > From: Jim Nasby [mailto:jim.na...@bluetreble.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
