Re: [HACKERS] path toward faster partition pruning - Mailing list pgsql-hackers

From David Rowley
Subject Re: [HACKERS] path toward faster partition pruning
Date
Msg-id CAKJS1f_0CfZaM2=+WQGRueb9B=4hxprb-bcT842jXPBkcfHQ5w@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] path toward faster partition pruning  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List pgsql-hackers
On 21 December 2017 at 23:38, Amit Langote
<Langote_Amit_f8@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


pgsql-hackers by date:

Previous
From: Haribabu Kommi
Date:
Subject: Enhance pg_stat_wal_receiver view to display connected host
Next
From: Ildar Musin
Date:
Subject: Re: General purpose hashing func in pgbench