Re: plan cache overhead on plpgsql expression

č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.

Regards

Pavel

> Regards
>
> Pavel
>
>>
>> Thanks,
>> Amit
>>
>