Re: Evaluate arguments of correlated SubPlans in the referencing ExprState
От | Andres Freund |
---|---|
Тема | Re: Evaluate arguments of correlated SubPlans in the referencing ExprState |
Дата | |
Msg-id | 20230302210031.o4vqzrwu3a2kplko@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Evaluate arguments of correlated SubPlans in the referencing ExprState (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Evaluate arguments of correlated SubPlans in the referencing ExprState
|
Список | 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 по дате отправления: