Re: Don't codegen deform code for virtual tuples in expr eval forscan 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 optimization is not performed (perhaps due to
> jit_optimize_above_cost)? Perhaps we could be more aggressive. We
> could maybe remove the opblock altogether. However, such a solution
> is not without complexity.

I'm doubtful this is worth the complexity - and not that we already have
plenty other places with zero length blocks.

WRT jit_optimize_above_cost not triggering, I think we need to replace
the "basic, unoptimized" codegen path with one that does cheap
optimizations only. The reason we don't do the full optimizations all
the time is that they're expensive, but there's enough optimizations
that are pretty cheap.  At some point we'll probably need our own
optimization pipeline, but I don't want to maintain that right now
(i.e. if some other people want to help with this aspect, cool)...

See also: https://www.postgresql.org/message-id/20190904152438.pv4vdk3ctuvvnxh3%40alap3.anarazel.de

Greetings,

Andres Freund