Re: Don't codegen deform code for virtual tuples in expr eval for scan fetch

Awesome! Thanks so much for all the review! :) -- Soumyadeep

Re: Don't codegen deform code for virtual tuples in expr eval for scan fetch

Hi, On 2019-09-30 09:14:45 -0700, Soumyadeep Chakraborty wrote: > I don't feel very strongly about the changes I proposed. > > > > I completely agree, that was an important consideration. > > > > > > I had some purely cosmetic suggestions: > > > 1. Rename ExecComputeSlotInfo to eliminate the

Re: Don't codegen deform code for virtual tuples in expr eval for scan fetch

Hi Andres, I don't feel very strongly about the changes I proposed. > > I completely agree, that was an important consideration. > > > > I had some purely cosmetic suggestions: > > 1. Rename ExecComputeSlotInfo to eliminate the need for the asserts. > > How does renaming it do so? I feel like

Re: Don't codegen deform code for virtual tuples in expr eval for scan fetch

Hi, On 2019-09-27 23:01:05 -0700, Soumyadeep Chakraborty wrote: > I completely agree, that was an important consideration. > > I had some purely cosmetic suggestions: > 1. Rename ExecComputeSlotInfo to eliminate the need for the asserts. How does renaming it do so? I feel like the asserts are a

Re: Don't codegen deform code for virtual tuples in expr eval for scan fetch

Hey, I completely agree, that was an important consideration. I had some purely cosmetic suggestions: 1. Rename ExecComputeSlotInfo to eliminate the need for the asserts. 2. Extract return value to a bool variable for slightly better readability. 3. Taking the opportunity to use TTS_IS_VIRTUAL.

Re: Don't codegen deform code for virtual tuples in expr eval for scan fetch

Hi, On 2019-09-25 22:11:51 -0700, Soumyadeep Chakraborty wrote: > Thank you very much for reviewing my patch! > > On Wed, Sep 25, 2019 at 1:02 PM Andres Freund wrote: > > IOW, wherever ExecComputeSlotInfo() is called, we should only actually > > push the expression step, when

Re: Don't codegen deform code for virtual tuples in expr eval for scan fetch

Hi Andres, Thank you for your insight and the link offered just the context I needed! On Wed, Sep 25, 2019 at 1:06 PM Andres Freund wrote: > > I'm doubtful this is worth the complexity - and not that we already have > plenty other places with zero length blocks. Agreed. On Wed, Sep 25, 2019

Re: Don't codegen deform code for virtual tuples in expr eval for scan fetch

Hello Andres, Thank you very much for reviewing my patch! On Wed, Sep 25, 2019 at 1:02 PM Andres Freund wrote: > 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

Re: Don't codegen deform code for virtual tuples in expr eval for scan fetch

Hi, On 2019-09-20 22:19:46 -0700, Soumyadeep Chakraborty wrote: > In my previous patch 0001, the resulting opblock consisted of a single > br instruction to it's successor opblock. Such a block represents > unnecessary overhead. Even though such a block would be optimized > away, what if

Re: Don't codegen deform code for virtual tuples in expr eval for scan fetch

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

Re: Don't codegen deform code for virtual tuples in expr eval for scan fetch

Hello, In my previous patch 0001, the resulting opblock consisted of a single br instruction to it's successor opblock. Such a block represents unnecessary overhead. Even though such a block would be optimized away, what if optimization is not performed (perhaps due to jit_optimize_above_cost)?