Thanks for the comments. On 2017/09/02 2:52, Robert Haas wrote: > 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.
OK. > > 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. Yeah. > 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. Agreed here too. I agree that spending effort on the first part (deferment of locking, etc. within the planner) does not benefit either the hash partitioning and run-time pruning patches much. > 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. Alright, I will try to do it that way. 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
