Re: [HACKERS] WIP: Faster Expression Processing v4
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] WIP: Faster Expression Processing v4 |
Дата | |
Msg-id | 8011.1490305255@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] WIP: Faster Expression Processing v4 (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [HACKERS] WIP: Faster Expression Processing v4
Re: [HACKERS] WIP: Faster Expression Processing v4 |
Список | 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 по дате отправления: