po 24. 2. 2020 v 18:56 odesílatel Pavel Stehule <pavel.steh...@gmail.com> napsal:
> > > po 24. 2. 2020 v 18:47 odesílatel Pavel Stehule <pavel.steh...@gmail.com> > napsal: > >> >> >> čt 20. 2. 2020 v 20:15 odesílatel Pavel Stehule <pavel.steh...@gmail.com> >> napsal: >> >>> >>> >>> st 19. 2. 2020 v 8:09 odesílatel Amit Langote <amitlangot...@gmail.com> >>> napsal: >>> >>>> On Wed, Feb 19, 2020 at 3:56 PM Amit Langote <amitlangot...@gmail.com> >>>> wrote: >>>> > On Wed, Feb 19, 2020 at 3:38 PM Pavel Stehule < >>>> pavel.steh...@gmail.com> wrote: >>>> > > st 19. 2. 2020 v 7:30 odesílatel Pavel Stehule < >>>> pavel.steh...@gmail.com> napsal: >>>> > >> út 18. 2. 2020 v 17:08 odesílatel Amit Langote < >>>> amitlangot...@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. Regards Pavel > > > > >> Regards >> >> Pavel >> >> >> >>> Regards >>> >>> Pavel >>> >>>> >>>> Thanks, >>>> Amit >>>> >>>
