Radical suggestion for plan executor?
I notice that the query executor currently has a lot of switch statements on
the the type of node it is descending to. This means you get a call tree
like:
ExecProcNode
ExecNestLoop
ExecProcNode
ExecMergeJoin
...
Wouldn't it be nicer if the Plan had access to function pointers that
already referred to the right function. So instead of:
result = ExecProcNode( a, b )
you get:
a->procs.exec( b );
It compresses the call tree down a bit. However, I'm not sure if it has many
benefits other than maintainability.
OTOH, you could keep ExecProcNode and just replace the switch with a
function call.
Any thoughts?
--
Martijn van Oosterhout <kleptog@svana.org>
http://svana.org/kleptog/
Show quoted text
It would be nice if someone came up with a certification system that
actually separated those who can barely regurgitate what they crammed over
the last few weeks from those who command secret ninja networking powers.
Martijn van Oosterhout <kleptog@svana.org> writes:
[ replace switch statements with function pointers ]
I've built systems both ways, and I can't say that I find any real
gain in transparency either way. I'm not excited about modifying
Postgres this way. Function pointers have some definite downsides:
debuggers can't always step through them, source code analysis tools
tend not to understand them too well either, etc etc.
If we were using C++ then the tradeoffs would be different, but
this system is just plain C...
regards, tom lane