Re: [HACKERS] path toward faster partition pruning

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: [HACKERS] path toward faster partition pruning
Дата
Msg-id CAKJS1f_7S389iuqhxR=pm6mEXztGF0fRBzSqmFjoU52SfCvonQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] path toward faster partition pruning  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Ответы Re: [HACKERS] path toward faster partition pruning  (David Rowley <david.rowley@2ndquadrant.com>)
Список pgsql-hackers
On 4 April 2018 at 00:02, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote:
> But actually, the presence of only Params in the pruning steps should
> result in the pruning not being invoked at all (at least for the static
> pruning case), thus selecting all partitions containing non-null data.  It
> is better to implement that instead of a workaround like scan_all_nonnulls
> side-channel I was talking about.

I don't think this is quite true. Since we're only using strict
clauses, a list of quals with just Params still means that NULLs can't
match. If you skip the step altogether then won't you have you've lost
the chance at pruning away any NULL-only partition?

I think it would be better to just have special handling in
get_matching_list_bound so that it knows it's performing <>
elimination. I'd thought about passing some other opstrategy but the
only safe one I thought to use was InvalidStrategy, which is already
used by NULL handling.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Foreign keys and partitioned tables