Re: [HACKERS] path toward faster partition pruning
От | David Rowley |
---|---|
Тема | Re: [HACKERS] path toward faster partition pruning |
Дата | |
Msg-id | CAKJS1f_0CfZaM2=+WQGRueb9B=4hxprb-bcT842jXPBkcfHQ5w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] path toward faster partition pruning (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Список | 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 по дате отправления: