Re: Special-case executor expression steps for common combinations

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Special-case executor expression steps for common combinations
Date: 2023-10-19 10:11:13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> On 12 Oct 2023, at 19:52, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2023-10-12 13:24:27 +0300, Heikki Linnakangas wrote:
>> 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 think it's mainly important for interpreted execution.


>>> 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.

Right, performance benefits aside it does improve readability IMHO.

> IIRC this is more interesting for JIT than the above, because it allows LLVM
> to know that the return value isn't needed and thus doesn't need to be
> computed.

Correct, this is important to the JIT code which no longer has to perform two
Loads and one Store in order to get nothing, but can instead fastpath to
building a zero returnvalue.

Daniel Gustafsson

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2023-10-19 10:42:50 RE: [PoC] pg_upgrade: allow to upgrade publisher node
Previous Message vignesh C 2023-10-19 09:41:59 Re: Initial Schema Sync for Logical Replication