On Fri, Aug 29, 2014 at 4:56 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > For scan plans, we need to prepare Append lists which are used to scan > for tuples in a partitioned relation. We can setup fake constraint > expressions based on the partitioning expressions, which let the planner > discard unnecessary partitions by way of constraint exclusion. > > (In the future we might be interested in creating specialized plan and > execution nodes that know more about partitioned relations, to avoid > creating useless Append trees only to prune them later.)
This seems like a big part of the point of doing first class partitions. If we have an equivalence class that specifies a constant for all the variables in the master expression then we should be able to look up the corresponding partition as a O(1) operation (or O(log(n) if it involves searching a list) rather than iterating over all the partitions and trying to prove lots of exclusions. We might even need a btree index to store the partitions so that we can handle scaling up and still find the corresponding partitions quickly. And I think there are still unanswered questions about indexes. You seem to be implying that users would be free to create any index they want on any partition. It's probably going to be necessary to support creating an index on the partitioned table which would create an index on each of the partitions and, crucially, automatically create corresponding indexes whenever new partitions are added. That said, everything that's here sounds pretty spot-on to me. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers