On Fri, Apr 15, 2016 at 5:46 AM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > Retaining the partition hierarchy would help to push-down join across > partition hierarchy effectively.
-1. You don't get to insert cruft into the final plan for the convenience of the optimizer. I think the AppendPath needs to be annotated with sufficient information to do whatever query planning optimizations we want, and some or all of that may need to carry over to the Append plan to allow run-time partition pruning. But I think that flattening nests of Appends is a good optimization and we should preserve it. If that makes the additional information that any given Append needs to carry a bit more complex, so be it. I also think it's very good that Amit has kept the query planner unchanged in this initial patch. Let's leave that work to phase two. What I suggest we do when the time comes is invent new nodes RangePartitionMap, ListPartitionMap, HashPartitionMap. Each contains minimal metadata needed for tuple routing or planner transformation. For example, RangePartitionMap can contain an array of partition boundaries - represented as Datums - and an array of mappings, each a Node *. The associated value can be another PartitionMap object if there is subpartitioning in use, or an OID. This can be used both for matching up partitions for join pushdown, and also for fast tuple routing and runtime partition pruning. > 2. The new syntax allows CREATE TABLE to be specified as partition of an > already partitioned table. Is it possible to do the same for CREATE FOREIGN > TABLE? Or that's material for v2? Similarly for ATTACH PARTITION. +1 for making CREATE FOREIGN TABLE support that also, and in version 1. And same for ATTACH PARTITION. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers