| From: | Ernst-Georg Schmid <pgchem(at)tuschehund(dot)de> |
|---|---|
| To: | "pgsql-interfaces(at)postgresql(dot)org" <pgsql-interfaces(at)postgresql(dot)org> |
| Subject: | Re: C trigger significantly slower than PL/pgSQL? |
| Date: | 2023-04-14 17:39:20 |
| Message-ID: | 8306edcc-8458-44b3-485b-0725de3c7743@tuschehund.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-interfaces |
> Yeah, there's your problem. Each time through the trigger, that query
> is being parsed, planned, and executed from scratch. plpgsql knows
> how to cache the planned statement, so it's doing less work per-call.
Hello again,
thank you for your help.
I have now used SPI_prepare() and SPI_keepplan() to cache the plan in a
static variable - and now it performs exactly like the PL/pgSQL version.
Which also probably means that either the Trigger is so trivial that C
makes no difference, or the observed TPS limit comes from somewhere else.
I have still a follow-up question, though. Since I'm not calling
SPI_freeplan(), the cached plan lives forever, right? Which is no
problem, since the trigger does the same statement over and over. But
does this generate a memory leak? Or is the saved plan tied to the
session and is deallocated when the session ends?
best regards
Ernst-Georg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2023-04-15 17:31:55 | Re: C trigger significantly slower than PL/pgSQL? |
| Previous Message | Tom Lane | 2023-04-13 15:42:11 | Re: C trigger significantly slower than PL/pgSQL? |