Re: Evaluate arguments of correlated SubPlans in the referencing ExprState - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Evaluate arguments of correlated SubPlans in the referencing ExprState
Date
Msg-id 20230302210031.o4vqzrwu3a2kplko@alap3.anarazel.de
Whole thread Raw
In response to Re: Evaluate arguments of correlated SubPlans in the referencing ExprState  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Evaluate arguments of correlated SubPlans in the referencing ExprState  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Hi,

On 2023-03-02 15:10:31 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2023-03-02 14:33:35 -0500, Tom Lane wrote:
> >> I looked through this, and there is one point that is making me really
> >> uncomfortable.  This bit is assuming that we can bind the address of
> >> the es_param_exec_vals array right into the compiled expression:
> 
> > Yea, I wasn't super comfortable with that either. I concluded it's ok
> > because we already cache pointers to the array inside each ExprContext.
> 
> ExprContext, sure, but compiled expressions?  Considering what it
> costs to JIT those, I think we ought to be trying to make them
> fairly long-lived.

I'm not opposed to EXPR_PARAM_SET, to be clear. I'll send an updated
version later. I was just thinking about the correctness in the current
world.

I think it's not just JIT that could benefit, fwiw. I think making
expressions longer lived could also help plpgsql tremendously, for
example.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Kirk Wolak
Date:
Subject: Re: proposal: psql: show current user in prompt
Next
From: Dmitry Koval
Date:
Subject: Re: Operation log for major operations