Re: Special-case executor expression steps for common combinations - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Special-case executor expression steps for common combinations
Date
Msg-id 526a60e6-a1a0-4320-83b4-54c82f271222@iki.fi
Whole thread Raw
In response to Special-case executor expression steps for common combinations  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: Special-case executor expression steps for common combinations  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 12/10/2023 12:48, Daniel Gustafsson wrote:
> The attached patch adds special-case expression steps for common sets of steps
> in the executor to shave a few cycles off during execution, and make the JIT
> generated code simpler.
> 
> * Adds EEOP_FUNCEXPR_STRICT_1 and EEOP_FUNCEXPR_STRICT_2 for function calls of
>    strict functions with 1 or 2 arguments (EEOP_FUNCEXPR_STRICT remains used for
>    > 2 arguments).
> * Adds EEOP_AGG_STRICT_INPUT_CHECK_ARGS_1 which is a special case for the
>    common case of one arg aggs.

Are these relevant when JITting? I'm a little sad if the JIT compiler 
cannot unroll these on its own. Is there something we could do to hint 
it, so that it could treat the number of arguments as a constant?

I understand that this can give a small boost in interpreter mode, so 
maybe we should do it in any case. But I'd like to know if we're missing 
a trick with the JITter, before we mask it with this.

> * Replace EEOP_DONE with EEOP_DONE_RETURN and EEOP_DONE_NO_RETURN to be able to
>    skip extra setup for steps which are only interested in the side effects.

I'm a little surprised if this makes a measurable performance 
difference, but sure, why not. It seems nice to be more explicit when 
you don't expect a return value.

-- 
Heikki Linnakangas
Neon (https://neon.tech)




pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Use virtual tuple slot for Unique node
Next
From: Aleksander Alekseev
Date:
Subject: Re: [PATCH] Compression dictionaries for JSONB