Re: plan cache overhead on plpgsql expression

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

In response to

Responses

Browse pgsql-hackers by date

  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