Re: calling procedures is slow and consumes extra much memory againstcalling function

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: calling procedures is slow and consumes extra much memory againstcalling function
Дата
Msg-id CAFj8pRCDTjSgOVm1bGc-XbW9NPT+dRDgLnWzKwHXCkdXhZvtWg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: calling procedures is slow and consumes extra much memory againstcalling function  (Amit Khandekar <amitdkhan.pg@gmail.com>)
Ответы Re: calling procedures is slow and consumes extra much memory againstcalling function  (Amit Khandekar <amitdkhan.pg@gmail.com>)
Список pgsql-hackers


st 10. 6. 2020 v 12:26 odesílatel Amit Khandekar <amitdkhan.pg@gmail.com> napsal:
On Sat, 16 May 2020 at 00:07, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
> Hi
>
>>>
>>> The problem is in plpgsql implementation of CALL statement
>>>
>>> In non atomic case -  case of using procedures from DO block, the expression plan is not cached, and plan is generating any time. This is reason why it is slow.
>>>
>>> Unfortunately, generated plans are not released until SPI_finish. Attached patch fixed this issue.
>>
>>
>> But now, recursive calling doesn't work :-(. So this patch is not enough
>
>
> Attached patch is working - all tests passed

Could you show an example testcase that tests this recursive scenario,
with which your earlier patch fails the test, and this v2 patch passes
it ? I am trying to understand the recursive scenario and the re-use
of expr->plan.

it hangs on plpgsql tests. So you can apply first version of patch

and "make check"


>
> It doesn't solve performance, and doesn't solve all memory problems, but significantly reduce memory requirements from 5007 bytes to 439 bytes per one CALL

So now  this patch's intention is to reduce memory consumption, and it
doesn't target slowness improvement, right ?

yes. There is a problem with planning every execution when the procedure was called from not top context.



--
Thanks,
-Amit Khandekar
Huawei Technologies

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions
Следующее
От: Odin Ugedal
Дата:
Сообщение: Re: [PATCH] Add support for choosing huge page size