|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Heikki Linnakangas <hlinnaka(at)iki(dot)fi>|
|Cc:||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-14 16:58:54 +0200, Heikki Linnakangas wrote:
> * execInterpExpr.c is quite a mouthful. How about exprInterpreter.c?
I applied most of your changes in the attached version.
* I quite like how the EEO_JUMP/EEO_NEXT stuff looks now / after your
change, that's clearly better.
* I reverted the removal of EEO_SWITCH() - pgindent goes a bit bonkers
if it can see the switch(), but not the case: statements.
* I re-added ExecEvalStepOp() - for one it's hugely useful during
debugging, for another I'm actually using it in a follow patch (So JIT
compilation can run after the interpreter has been initialized).
Added code guaranteeing that we can't run
* Renamed EEO_* opcode enum members to EEOP_* as suggested
* I've not yet renamed execInterpExpr.c - I don't like execInterpreter.c
because it doesn't reference expressions and execExprInterpreter.c
seems a bit long - but I can live with both (preferring the
latter). Not that surprisingly I can also live with execInterpExpr.c ;)
* Addressed your size_t sizing concern by using, as is proper anyway,
* I tried to clarify the comment in execExpr.c's header that you marked
as hard to understand.
|Next Message||Andres Freund||2017-03-14 22:49:59||Re: WIP: Faster Expression Processing v4|
|Previous Message||Douglas Doole||2017-03-14 22:31:50||Re: WIP: Faster Expression Processing v4|