Re: Reducing expression evaluation overhead

Sailesh Krishnamurthy <sailesh(at)cs(dot)berkeley(dot)edu> writes:

> >>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 switch with function pointers as I
> don't think branch prediction helps much with varying switch arms
> selected with different exprs. Also I agree that the delta of indirect
> function invocation is probably small.

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. However worrying about branch prediction is
probably being premature when the amount of time being spend here is so large.

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? You only need one pointer for each node type, not
one for every node. NodeTags start at 0 and the highest is 900, so we're
talking about a 4k lookup table on a 32 bit machine.

> I've forgotten the syntax of case, but for the simple form isn't
> expr=const going to be the same expr for each case arm ? If that's the
> case, couldn't we actually save the value of expr in a Datum and then
> reuse that (through a Const) in each of the other arms to evaluate the
> actual exprs ? That should reduce the number of times ExecEvalVar (and
> through it heapgetattr) are called.

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 postgres's extensible types though. I
guess if postgres can see that every arm of the CASE is a '=' expression one
side of which is a constant expression and all of the same type then it could
use the same operators that the hash index code uses? That seems like it would
be a lot of work though.

--
greg