On Wed, Feb 19, 2020 at 3:56 PM Amit Langote <amitlangote09@gmail.com> wrote: > On Wed, Feb 19, 2020 at 3:38 PM Pavel Stehule <pavel.stehule@gmail.com> wrote: > > st 19. 2. 2020 v 7:30 odesílatel Pavel Stehule <pavel.stehule@gmail.com> napsal: > >> út 18. 2. 2020 v 17:08 odesílatel Amit Langote <amitlangote09@gmail.com> napsal: > >>> > I updated the patch to do that. > >>> > > >>> > With the new patch, `select foo()`, with inline-able sql_incr() in it, > >>> > runs in 679 ms. > >>> > > >>> > Without any inline-able function, it runs in 330 ms, whereas with > >>> > HEAD, it takes 590 ms. > >>> > >>> I polished it a bit. > >> > >> > >> the performance looks very interesting - on my comp the execution time of 100000000 iterations was decreased from 34 sec to 15 sec, > >> > >> So it is interesting speedup > > > > but regress tests fails > > Oops, I failed to check src/pl/plpgsql tests. > > Fixed in the attached.
Added a regression test based on examples discussed here too.
It is working without problems
I think this patch is very interesting for Postgres 13
I checked a performance of this patch again and I think so there is not too much space for another optimization - maybe JIT can help.
There is relative high overhead of call of strict functions - the params are repeatedly tested against NULL.
But I found one issue - I don't know if this issue is related to your patch or plpgsql_check.
plpgsql_check try to clean after it was executed - it cleans all plans. But some pointers on simple expressions are broken after catched exceptions.
expr->plan = 0x80. Is interesting, so other fields of this expressions are correct.
I am not sure, but after patching the SPI_prepare_params the current memory context is some short memory context.
Can SPI_prepare_params change current memory context? It did before. But after patching different memory context is active.