Postgres Pro
Downloads
Home   >   mailing lists

Re: Don't codegen deform code for virtual tuples in expr eval forscan fetch - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Don't codegen deform code for virtual tuples in expr eval forscan fetch
Date
Msg-id 20190925200210.aled756suzad674w@alap3.anarazel.de
Whole thread Raw
In response to Don't codegen deform code for virtual tuples in expr eval for scan fetch  (Soumyadeep Chakraborty <soumyadeep2007@gmail.com>)
Responses Re: Don't codegen deform code for virtual tuples in expr eval forscan fetch
List pgsql-hackers
Tree view 
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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Allow to_date() and to_timestamp() to accept localized names
Next
From: Alvaro Herrera
Date:
Subject: Re: Add FOREIGN to ALTER TABLE in pg_dump