From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Evaluate arguments of correlated SubPlans in the referencing ExprState |
Date: | 2023-03-02 21:00:31 |
Message-ID: | 20230302210031.o4vqzrwu3a2kplko@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2023-03-02 15:10:31 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Koval | 2023-03-02 21:09:38 | Re: Operation log for major operations |
Previous Message | Kirk Wolak | 2023-03-02 20:45:10 | Re: proposal: psql: show current user in prompt |