Re: [HACKERS] WIP: Faster Expression Processing v4 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] WIP: Faster Expression Processing v4
Date
Msg-id 20170324004323.ne75fud572d4t53s@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] WIP: Faster Expression Processing v4  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,m

On 2017-03-23 17:40:55 -0400, Tom Lane wrote:
> Stylistic thought ... I am wondering if it wouldn't be a good idea
> to replace EEOP_CASE_WHEN_STEP, EEOP_CASE_THEN_STEP, EEOP_COALESCE,
> and EEOP_ARRAYREF_CHECKINPUT with instructions defined in a less
> usage-dependent way as
> 
>     EEOP_JUMP        unconditional jump
>     EEOP_JUMP_IF_NULL    jump if step result is null
>     EEOP_JUMP_IF_NOT_NULL    jump if step result isn't null
>     EEOP_JUMP_IF_NOT_TRUE    jump if step result isn't TRUE
> 
> One could imagine later filling out this set with the other BoolTest
> condition types, but that seems to be all we need right now.

Hm, no arguments against, but I'm also not particularly excited about
the change.


> These are basically just renamings of the step types that exist now,
> although EEOP_ARRAYREF_CHECKINPUT would have to drop its not-very-
> necessary Assert(!op->d.arrayref.state->isassignment).

I won't shed a tear about that assert's removal.


> Well, I guess I should say that they're renamings of the semantics
> that I have for these steps in my working copy; for instance, I got
> rid of casewhen.value/casewhen.isnull in favor of letting CASE WHEN
> expressions evaluate into the CASE's final output variable.

That sounds like a sensible change (in the abstract, I obviously haven't
seen your working copy).


Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] WIP: Faster Expression Processing v4
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] WIP: Faster Expression Processing v4