Re: plan cache overhead on plpgsql expression

po 24. 2. 2020 v 18:56 odesílatel Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
napsal:

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