Re: [HACKERS] path toward faster partition pruning

On 21 December 2017 at 23:38, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)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