Re: [HACKERS] path toward faster partition pruning
От | David Rowley |
---|---|
Тема | Re: [HACKERS] path toward faster partition pruning |
Дата | |
Msg-id | CAKJS1f_y-PvJBjCKtGepz7vPsQupRzqUhHzwX+i6ZGWg3J2PZg@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
Re: [HACKERS] path toward faster partition pruning Re: [HACKERS] path toward faster partition pruning |
Список | pgsql-hackers |
On 12 December 2017 at 22:13, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote: > Attached updated patches. Hi Amit, I'm sorry to say this is another micro review per code I'm stumbling over when looking at the run-time partition pruning stuff. 1. In get_partitions_from_clauses_recurse(), since you're assigning the result to the first input, the following should use bms_add_members and not bms_union. The logical end result is the same, but using bms_union means a wasted palloc and a small memory leak within the memory context. /* * Partition sets obtained from mutually-disjunctive clauses are * combined using set union. */ or_partset = bms_union(or_partset, arg_partset); 2. Also in get_partitions_from_clauses_recurse(), it might also be worth putting in a bms_free(or_partset) after: /* * Partition sets obtained from mutually-conjunctive clauses are * combined using set intersection. */ result = bms_intersect(result, or_partset); Also, instead of using bms_intersect here, would it be better to do: result = bms_del_members(result, or_partset); ? That way you don't do a bms_copy and leak member for each OR branch since bms_intersect also does a bms_copy() The resulting set could end up with a few more trailing 0 words than what you have now, but it to be a better idea not allocate a new set each time. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: