Re: calling procedures is slow and consumes extra much memory againstcalling function
От | Amit Khandekar |
---|---|
Тема | Re: calling procedures is slow and consumes extra much memory againstcalling function |
Дата | |
Msg-id | CAJ3gD9eZmJawjGtbZ2SF53Me3A0OomZa3czPzP7kVNH4oQ2FHQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: calling procedures is slow and consumes extra much memory againstcalling function (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: calling procedures is slow and consumes extra much memory againstcalling function
|
Список | pgsql-hackers |
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 generatingany 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 doesn't solve performance, and doesn't solve all memory problems, but significantly reduce memory requirements from5007 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 ? -- Thanks, -Amit Khandekar Huawei Technologies
В списке pgsql-hackers по дате отправления: