| From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Subject: | Re: calling procedures is slow and consumes extra much memory against calling function |
| Date: | 2020-05-15 18:36:20 |
| Message-ID: | CAFj8pRAMHei7eWOkCTsiKxh3BPUaCbJFuVySn+R+Qk9dfNOFTw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
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
Regards
Pavel
>
>
>> Regards
>>
>> Pavel
>>
>>
>>> Regards
>>>
>>> Pavel
>>>
>>>
| Attachment | Content-Type | Size |
|---|---|---|
| plpgsql-call-fix.patch | text/x-patch | 1.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christopher Baines | 2020-05-15 20:30:26 | [PATCH] Fix pg_dump --no-tablespaces for the custom format |
| Previous Message | Shichao Jin | 2020-05-15 18:22:49 | Spawned Background Process Knows the Exit of Client Process? |