On 21 December 2017 at 23:38, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/12/20 17:27, Amit Langote wrote: > I think I was able to make this work and in the process of making it work, > also came to the conclusion that this could be made to work sensibly > *only* for list partitioned tables. That's because one cannot prune a > given partition using a set of <> operator clauses, if we cannot be sure > that those clauses exclude *all* values of the partition key allowed by > that partition. It's only possible to do that for a list partitioned > table, because by definition one is required to spell out every value that > a given partition of such table allows.
Makes sense. Thanks for fixing LIST partitioning to work with that. We have no way to know that there's no value between 1::int and 2::int, so it's completely understandable why this can't work for RANGE. HASH is also understandable since we don't have a complete picture of all the values that can be contained within the partition. I'll try to do another complete review of v16 soon. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
