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

From: Andres Freund <andres(at)anarazel(dot)de>
To: Soumyadeep Chakraborty <soumyadeep2007(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Don't codegen deform code for virtual tuples in expr eval for scan fetch
Date: 2019-09-25 20:02:10
Message-ID: 20190925200210.aled756suzad674w@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-09-25 20:04:06 Re: Add FOREIGN to ALTER TABLE in pg_dump
Previous Message Alvaro Herrera 2019-09-25 19:57:45 Re: Allow to_date() and to_timestamp() to accept localized names