Re: plan cache overhead on plpgsql expression
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Amit Langote <amitlangote09@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2020-02-24T17:56:55Z
Lists: pgsql-hackers
po 24. 2. 2020 v 18:47 odesílatel Pavel Stehule <pavel.stehule@gmail.com> napsal: > > > čt 20. 2. 2020 v 20:15 odesílatel Pavel Stehule <pavel.stehule@gmail.com> > napsal: > >> >> >> st 19. 2. 2020 v 8:09 odesílatel Amit Langote <amitlangote09@gmail.com> >> napsal: >> >>> On Wed, Feb 19, 2020 at 3:56 PM Amit Langote <amitlangote09@gmail.com> >>> wrote: >>> > On Wed, Feb 19, 2020 at 3:38 PM Pavel Stehule <pavel.stehule@gmail.com> >>> wrote: >>> > > st 19. 2. 2020 v 7:30 odesílatel Pavel Stehule < >>> pavel.stehule@gmail.com> napsal: >>> > >> út 18. 2. 2020 v 17:08 odesílatel Amit Langote < >>> amitlangote09@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. > Regards > > Pavel > > > >> Regards >> >> Pavel >> >>> >>> Thanks, >>> Amit >>> >>
Commits
-
Rearrange validity checks for plpgsql "simple" expressions.
- fbc7a716084e 13.0 landed
-
Improve performance of "simple expressions" in PL/pgSQL.
- 8f59f6b9c037 13.0 landed
-
Ensure that plpgsql cleans up cleanly during parallel-worker exit.
- 4bfacc5a4411 9.5.22 landed
- deeda011b316 11.8 landed
- dd51b5696aa5 9.6.18 landed
- a54a87320782 12.3 landed
- 86e5badd22d9 13.0 landed
- 42d3649b58f4 10.13 landed