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
