Re: Extensible executor nodes for preparation of SQL/MED

Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> writes:
> SQL/MED will have some kinds of planner hooks to support FDW-depending
> plan execution. Then, we will need to support user-defined executor nodes.
> The proposed SQL/MED has own "executor node hooks" in ForeignTableScan,
> http://wiki.postgresql.org/wiki/SQL/MED#Executor
> but I think it will be cleaner to support it in executor level.

I think the argument that this is good for FDW is bogus: there is
no evidence whatsoever that we need add-on plan node types, and if
we did need them, we'd need a whole lot more infrastructure than
what you're sketching (see EXPLAIN for instance, not to mention
how will the planner generate them in the first place).

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?

One comment is that as sketched, this requires two extra levels of
indirection at runtime, for no particular benefit that I can see.
It'd be better to put the function pointers right in the planstate
nodes, at least for the most common case of ExecProcNode.

regards, tom lane