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