Greg Stark <gsstark@mit.edu> writes:
> a) I don't see why you would assume branch prediction would be ineffective
> here. There are probably a few arms of the switch that are more common than
> all the others, especially when a large query is evaluating the same
> expression over and over again.
Sure, but the problem from the CPU's point of view is that the pattern
isn't 11111111...2222222...3333333 but 123123123123123... For instance
when evaluating "var op const" over and over, as in this example, the
branches will go to ExecEvalVar, ExecEvalConst, ExecEvalOper,
ExecEvalVar, ExecEvalConst, etc etc. I know of no modern CPU that will
guess right in that scenario. Inlining ExecEvalExpr will push back this
uncertainty to the call points --- which won't make things better, but
can't make 'em any worse either.
> However worrying about branch prediction is probably being premature
True, I'm not sure that it's really an issue. On the other hand, I have
measurements on two different architectures that show ExecEvalExpr being
an unreasonably large fraction of the runtime. Given that there's
hardly anything in there except a switch(), Sailesh's idea that branch
misprediction is part of the problem seems like a reasonable thought.
> b) Instead of storing one of a small set of function pointers in every
> node of every expression, wouldn't it make more sense to have a table
> lookup from node type to function pointer?
That's pretty much what the ExecEvalExpr switch() does already, on most
modern architectures.
regards, tom lane
