Re: [HACKERS] Runtime Partition Pruning
| От | Amit Langote |
|---|---|
| Тема | Re: [HACKERS] Runtime Partition Pruning |
| Дата | |
| Msg-id | 2dbe3de6-ad07-655f-1278-356709cbf185@lab.ntt.co.jp обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Runtime Partition Pruning (David Rowley <david.rowley@2ndquadrant.com>) |
| Ответы |
Re: [HACKERS] Runtime Partition Pruning
|
| Список | pgsql-hackers |
Hi David. On 2018/02/23 20:34, David Rowley wrote: > On 22 February 2018 at 22:31, Amit Langote > <Langote_Amit_f8@lab.ntt.co.jp> wrote: >> Some comments: >> >> * I noticed that the patch adds a function to bitmapset.c which you might >> want to extract into its own patch, like your patch to add bms_add_range() >> that got committed as 84940644d [2]. > > I've made that 0001 in the series Thanks. > I've attached an updated set of patches. > > I hope this also addresses Rajkumar reported crash. I ended up making > some changes to how the Param values are determined by reusing more of > the existing executor code rather than duplicating it in > partkey_datum_from_expr. I really could use a sanity check on my > changes to that function now, especially the cross type portion. I've incorporated portions of 0002 and 0003 into my patch on the other thread (v34) posted at [1]. That is, mostly the changes around handling OR clauses and interface changes resulting from it. Attached are revised version of your patches after the aforementioned rearrangements. Note that after I took out the optimizer portion of the 0003 patch to incorporate it into my patch (OR clause processing bits), not much was left in it, so I squashed it into 0002. So there are only 0001 and 0002. As a review comment on 0002, I think trypartitionprune is better written as try_partition_prune. Thanks, Amit [1] https://www.postgresql.org/message-id/158f04ce-9deb-0457-ddcc-78fb73db4ebc%40lab.ntt.co.jp
Вложения
В списке pgsql-hackers по дате отправления: