Re: plan cache overhead on plpgsql expression - Mailing list pgsql-hackers

From Amit Langote
Subject Re: plan cache overhead on plpgsql expression
Date
Msg-id CA+HiwqG2FnRmZJVLZxeTK48h+fiXVA+Rht7fqE9yJLRH7fZ3cw@mail.gmail.com
Whole thread Raw
In response to Re: plan cache overhead on plpgsql expression  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: plan cache overhead on plpgsql expression  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Mar 26, 2020 at 4:44 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Pavel Stehule <pavel.stehule@gmail.com> writes:
> > I'll mark this patch as ready for commiters.
>
> Thanks for reviewing!  Amit, do you have any thoughts on this?

Thanks for picking this up.  Test cases added by your patch really
shows why the plancache and the planner must not be skipped, something
I totally failed to grasp.

I can't really see any problem with your patch, but mainly due to my
unfamiliarity with some of the more complicated things it touches,
like resowner stuff.

One thing -- I don't get the division between
CachedPlanAllowsSimpleValidityCheck() and CachedPlanIsSimplyValid().
Maybe I am missing something, but could there not be just one
function, possibly using whether expr_simple_expr is set or not to
skip or do, resp., the checks that the former does?

--
Thank you,

Amit Langote
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: Memory-Bounded Hash Aggregation
Next
From: Fujii Masao
Date:
Subject: Re: Planning counters in pg_stat_statements (using pgss_store)