Re: Don't codegen deform code for virtual tuples in expr eval forscan fetch
От | Andres Freund |
---|---|
Тема | Re: Don't codegen deform code for virtual tuples in expr eval forscan fetch |
Дата | |
Msg-id | 20190925200210.aled756suzad674w@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Don't codegen deform code for virtual tuples in expr eval for scan fetch (Soumyadeep Chakraborty <soumyadeep2007@gmail.com>) |
Ответы |
Re: Don't codegen deform code for virtual tuples in expr eval forscan fetch
|
Список | pgsql-hackers |
Hi, Thanks for working on this! On 2019-09-17 23:54:51 -0700, Soumyadeep Chakraborty wrote: > This is to address a TODO I found in the JIT expression evaluation > code (opcode = > EEOP_INNER_FETCHSOME/EEOP_OUTER_FETCHSOME/EEOP_SCAN_FETCHSOME): > > * TODO: skip nvalid check if slot is fixed and known to > * be a virtual slot. I now think this isn't actually the right approach. Instead of doing this optimization just for JIT compilation, we should do it while generating the ExprState itself. That way we don't just accelerate JITed programs, but also normal interpreted execution. IOW, wherever ExecComputeSlotInfo() is called, we should only actually push the expression step, when ExecComputeSlotInfo does not determine that a) the slot is virtual, b) and fixed (i.e. guaranteed to always be the same type of slot). Does that make sense? Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: