Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning
От | Richard Guo |
---|---|
Тема | Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning |
Дата | |
Msg-id | CAMbWs49G1ymH=W9puoUEX5FfXcKGThbgWsx6Hmb3Dp6SJ9uSmg@mail.gmail.com обсуждение исходный текст |
Ответ на | Memory consumed by child SpecialJoinInfo in partitionwise join planning (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>) |
Ответы |
Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning
|
Список | pgsql-hackers |
On Thu, Jul 27, 2023 at 10:10 PM Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> wrote:
The attached patch (0002) fixes this issue by
1. declaring child SpecialJoinInfo as a local variable, thus
allocating memory on the stack instead of CurrentMemoryContext. The
memory on the stack is freed automatically.
2. Freeing the Relids in SpecialJoinInfo explicitly after
SpecialJoinInfo has been used.
it's OK to construct and free the SpecialJoinInfo for a child join on
the fly. So the approach in 0002 looks reasonable to me. But there is
something that needs to be fixed in 0002.
+ bms_free(child_sjinfo->commute_above_l);
+ bms_free(child_sjinfo->commute_above_r);
+ bms_free(child_sjinfo->commute_below_l);
+ bms_free(child_sjinfo->commute_below_r);
These four members in SpecialJoinInfo only contain outer join relids.
They do not need to be translated. So they would reference the same
memory areas in child_sjinfo as in parent_sjinfo. We should not free
them, otherwise they would become dangling pointers in parent sjinfo.
Thanks
Richard
В списке pgsql-hackers по дате отправления: