On Sat, 16 May 2020 at 00:07, Pavel Stehule <pavel.steh...@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 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 ? -- Thanks, -Amit Khandekar Huawei Technologies
