|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org|
|Subject:||Re: WIP: Faster Expression Processing v4|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
> 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).
|Next Message||Andres Freund||2017-03-24 00:47:34||Re: WIP: Faster Expression Processing v4|
|Previous Message||Tom Lane||2017-03-24 00:36:32||Re: WIP: Faster Expression Processing v4|