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  (Soumyadeep Chakraborty <soumyadeep2007@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Allow to_date() and to_timestamp() to accept localized names
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Add FOREIGN to ALTER TABLE in pg_dump