From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: plan cache overhead on plpgsql expression |
Date: | 2020-02-24 17:56:55 |
Message-ID: | CAFj8pRCJ7S5FU-ums8W7fEBidsftgb+oUNj8gC68tFhy_xD3qQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
> Regards
>
> Pavel
>
>
>
>> Regards
>>
>> Pavel
>>
>>>
>>> Thanks,
>>> Amit
>>>
>>
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2020-02-24 18:29:51 | Re: pgsql: Add kqueue(2) support to the WaitEventSet API. |
Previous Message | Juan José Santamaría Flecha | 2020-02-24 17:56:05 | Re: BUG #16108: Colorization to the output of command-line has unproperly behaviors at Windows platform |