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

From Tom Lane
Subject Re: [HACKERS] WIP: Faster Expression Processing v4
Date
Msg-id 8011.1490305255@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] WIP: Faster Expression Processing v4  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] WIP: Faster Expression Processing v4  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] WIP: Faster Expression Processing v4  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
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 jumpEEOP_JUMP_IF_NULL    jump if step result is nullEEOP_JUMP_IF_NOT_NULL    jump if
stepresult isn't nullEEOP_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.

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

At least to me, I think the compiling code would be more readable
this way.  I find WHEN_STEP and THEN_STEP a bit odd because they are
emitted after, not before, the expressions you'd think they control.
ARRAYREF_CHECKINPUT is pretty vaguely named, too.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: [HACKERS] Measuring replay lag
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Potential data loss of 2PC files