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  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Список 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 doesn't seem too expensive to translate SpecialJoinInfos, so I think
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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Support worker_spi to execute the function dynamically.
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Support worker_spi to execute the function dynamically.