Re: Evaluate arguments of correlated SubPlans in the referencing ExprState

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

In response to

Responses

Browse pgsql-hackers by date

  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