Re: [HACKERS] path toward faster partition pruning
От | David Rowley |
---|---|
Тема | Re: [HACKERS] path toward faster partition pruning |
Дата | |
Msg-id | CAKJS1f-j7qRbS_ZYMRXUr-MSg940KdiPsqtKtav+hojf0qQK-Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] path toward faster partition pruning (David Rowley <david.rowley@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] path toward faster partition pruning
|
Список | pgsql-hackers |
On 4 April 2018 at 09:47, David Rowley <david.rowley@2ndquadrant.com> wrote: > 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. I'm currently working up a patch to do this the way I think is best. I'll submit it soon and we can review and get your thoughts on it. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: