On Thu, Aug 31, 2017 at 2:02 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > Attached is now also the set of patches that implement the actual > partition-pruning logic, viz. the last 3 patches (0004, 0005, and 0006) of > the attached.
It strikes me that this patch set is doing two things but maybe in the opposite order that I would have chosen to attack them. First, there's getting partition pruning to use something other than constraint exclusion. Second, there's deferring work that is currently done at an early stage of the process until later, so that we waste less effort on partitions that are ultimately going to be pruned. The second one is certainly a worthwhile goal, but there are fairly firm interdependencies between the first one and some other things that are in progress. For example, the first one probably ought to be done before hash partitioning gets committed, because constraint-exclusion based partitioning pruning won't work with partitioning pruning, but some mechanism based on asking the partitioning code which partitions might match will. Such a mechanism is more efficient for list and range partitions, but it's the only thing that will work for hash partitions. Also, Beena Emerson is working on run-time partition pruning, and the more I think about it, the more I think that overlaps with this first part. Both patches need a mechanism to identify, given a btree-indexable comparison operator (< > <= >= =) and a set of values, which partitions might contain matching values. Run-time partition pruning will call that at execution time, and this patch will call it at plan time, but it's the same logic; it's just a question of the point at which the values are known. And of course we don't want to end up with two copies of the logic. Therefore, IMHO, it would be best to focus first on how we're going to identify the partitions that survive pruning, and then afterwards work on transposing that logic to happen before partitions are opened and locked. That way, we get some incremental benefit sooner, and also unblock some other development work. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
