Greg Stark [EMAIL PROTECTED] writes:
That's not true all the time, but I know 90% of my case statements are of this
form. In some ideal world postgres would recognize this form and handle it
specially using some kind of quick hash table lookup.
I don't see how to reconcile that with
Tom == Tom Lane [EMAIL PROTECTED] writes:
Tom The idea I was toying with is to generate, not x = y with
Tom repeated copies of x, but placeholder = y where placeholder
Tom is a dummy expression tree node. Then at runtime, the CASE
Tom code would evaluate the test expression once
I've been looking at an example provided by Arjen van der Meijden in
which practically all the runtime goes into evaluating very trivial
comparison expressions (it's basically a CASE statement with a huge
number of arms). Whether or not you think that a CASE with a huge
number of arms is a
Tom == Tom Lane [EMAIL PROTECTED] writes:
Tom I'm not sure that this would let us catch up to what Arjen
Tom reports as MySQL's expression evaluation speed, but it should
Tom at least speed things up a bit with only fairly localized
Tom changes.
I like the idea of memoizing the
Sailesh Krishnamurthy [EMAIL PROTECTED] writes:
I like the idea of memoizing the switch with function pointers as I
don't think branch prediction helps much with varying switch arms
selected with different exprs.
Check, it's hard to see how any CPU could get much traction on the
behavior of
Sailesh Krishnamurthy [EMAIL PROTECTED] writes:
Tom == Tom Lane [EMAIL PROTECTED] writes:
Tom I'm not sure that this would let us catch up to what Arjen
Tom reports as MySQL's expression evaluation speed, but it should
Tom at least speed things up a bit with only fairly
Greg Stark [EMAIL PROTECTED] 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.
Tom Lane [EMAIL PROTECTED] writes:
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
