Re: Special-case executor expression steps for common combinations

> On 13 Sep 2024, at 15:01, Andreas Karlsson <andreas@proxel.se> wrote:
> 
> On 9/10/24 10:54 AM, Daniel Gustafsson wrote:
>>> On 22 Jul 2024, at 23:25, Andreas Karlsson <andreas@proxel.se> wrote:
>>> 
>>> I have bench marked the two patches now and failed to measure any speedup or slowdown from the first patch (removing return) but I think it is a good idea anyway.
>>> 
>>> For the second patch (optimize strict) I managed to measure a ~1% speed up for the following query "SELECT sum(x + y + 1) FROM t;" over one million rows.
>> That's expected, this is mostly about refactoring the code to simplifying the
>> JITed code (and making tiny strides towards JIT expression caching).
> 
> Yup! Expected and nice tiny speedup.
> 
>>> I would say both patches are ready for committer modulo my proposed style fixes.
>> I am a bit wary about removing the out_error label and goto since it may open
>> up for reports from static analyzers about control reaching the end of a
>> non-void function without a return. The other change has been incorporated.
>> The attached v3 is a rebase to handle executor changes done since v2, with the
>> above mentioned fix as well.  If there are no objections I think we should
>> apply this version.
> 
> Sounds good to me and in my opinion this is ready to be committed.

This fell off the ever-growing TODO again.  Re-reading it I still think it's a
good idea, it applied almost cleanly still and still gives a slight performance
improvement along with the more interesting refactoring which will make caching
of expressions easier down the line.

Attached is a rebased v4, unless there are objections I'll go ahead with this
version.

--
Daniel Gustafsson