st 10. 6. 2020 v 12:26 odesÃlatel Amit Khandekar <amitdkhan...@gmail.com> napsal:
> 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 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 >
