From: Amit Kapila [mailto:amit.kapil...@gmail.com] > > > How would you distinguish values in list partition for multiple > > > columns? I mean for range partition, we are sure there will > > > be either one value for each column, but for list it could > > > be multiple and not fixed for each partition, so I think it will not > > > be easy to support the multicolumn partition key for list > > > partitions. > > >Irrespective of difficulties of representing it using pg_node_tree, it seems > >to me that multicolumn list partitioning is not widely used. > > So I think it is better to be clear why we are not planning to > support it, is it that because it is not required by users or > is it due to the reason that code seems to be tricky or is it due > to both of the reasons. It might help us if anyone raises this > during the development of this patch or in general if someone > requests such a feature.
Coming back to the how pg_node_tree representation for list partitions - For each column in a multicolumn list partition key, a value would look like a dumped Node for List of Consts (all allowed values in a given list partition). And the whole key would then be a List of such Nodes (a dump thereof). That's perhaps pretty verbose but I guess that's supposed to be only a catalog representation. During relcache building, we turn this back into a collection of structs to efficiently locate the partition of interest whatever the method of doing that ends up being (based on partition type). The relcache step ensures that we have decoupled the concern of quickly locating an interesting partition from its catalog representation. Of course, there may be flaws in this picture and would only reveal themselves when actually trying to implement it or they can be pointed out in advance. 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
