Here is a WIP patch to extensible executor nodes.
It replaces large switch blocks with function-pointer calls (renamed to
PlanProcs from VTable). It has small performance win (Please test it!)
and capsulize some details of executor nodes, but is not perfect.
The infrastructure might be used by SQL/MED, but then not only PlanState
but also Plan and Path are required to be customizable. Complete cleanup
would be difficult, but I'm trying to find common ground for existing
postgres' implementation and extensible planner and executor.
Comments and suggestions welcome.
On Tue, Oct 26, 2010 at 12:21 PM, Itagaki Takahiro
<itagaki.takahiro@gmail.com> wrote:
> I didn't intend performance, but there is small but measurable win
> in it if I avoided indirections. We might not always need to copy
> a whole vtable into planstate; only ExecProcNode might be enough.
> I'll continue the research.
>
> 24957.767 ms : master (a big switch)
> 25059.838 ms : two indirections (planstate->plan->vtable->fn)
> 24819.298 ms : one indirection (planstate->plan->vtable.fn)
> 24118.436 ms : direct call (planstate->vtable.fn)
>
> So, major benefits of the change might be performance and code refactoring.
> Does anyone have comments about it for the functionality? It might also be
> used by SQL/MED and executor hooks, but I have no specific idea yet.
--
Itagaki Takahiro
