Re: Extensible executor nodes for preparation of SQL/MED

Greg Stark <gsstark(at)mit(dot)edu> writes:
> On Mon, Oct 25, 2010 at 8:28 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> But it might be a good change anyway from a performance standpoint,
>> in case a call through a function pointer is faster than a big switch.
>> Have you tried benchmarking it on common platforms?

> I've always wondered why we didn't use function pointers. It seems
> like it would make the code a lot easier to maintain with fewer places
> that need to be updated every time we add a node.

> But I always assumed a big part of the reason was performance.
> Generally compilers hate optimizing code using function pointers. They
> pretty much kill any inter-procedural optimization since it's very
> hard to figure out what set of functions you might have called and
> make any deductions about what side effects those functions might or
> might not have had. Even at the chip level function pointers tend to
> be slow since they cause full pipeline stalls where the processor has
> no idea where the next instruction is coming from until it's finished
> loading the data from the previous instruction.

At least in the case of the plan-node-related switches, the called
functions tend to be big and ugly enough that it's really hard to credit
any meaningful inter-procedural optimization could happen. Side effects
would have to be "pretty much everything".

> On the other hand of course it's not obvious what algorithm gcc should
> use to implement largish switch statements like these. It might be
> doing a fairly large number of operations doing a binary search or
> hash lookup to determine which branch to take.

I confess to not having actually examined the assembly code anytime
recently, but I'd always supposed it would be an array-lookup anytime
the set of case labels was reasonably dense, which it should be in these
cases. So I'm not sure I believe the pipeline stall argument either.
Any way you slice it, there's going to be a call to a function that
is going to be really really hard to predict in advance --- unless of
course you rely on statistics like "where did I jump to the last few
times I was here", which I think modern CPUs do have the ability to
do.

But this is all just arm-waving of course. Benchmarks would be a lot
more convincing.

regards, tom lane