Skip site navigation (1) Skip section navigation (2)

Extensible executor nodes for preparation of SQL/MED

From: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Extensible executor nodes for preparation of SQL/MED
Date: 2010-10-25 11:16:49
Message-ID: AANLkTim+F5uUEyS0OZxjxQ=3B6g2iwSnqXy+qmVHjCX-@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

The attached patch is an experimental code to do it; Plan struct has
"vtable" field as a set of functions to generate and execute PlanState
nodes. It changes large switch-case blocks in the current executor
into function-pointer calls as like as virtual functions in C++.

Is it worth doing? If we will go to the direction, I'll continue to
research it, like extensibility of Path nodes and EXPLAIN support.

-------- Essence of the patch --------
typedef struct Plan
{
    NodeTag     type;
    PlanVTable *vtable;	/* executor procs */
...

struct PlanVTable
{
    ExecInitNode_type   InitNode;
    ExecProcNode_type   ProcNode;
    MultiProcNode_type  MultiProcNode;
    ExecEndNode_type    EndNode;
...

make_seqscan()
{
    node = makeNode(SeqScan);
    node->vtable = &SeqScanVTable;
...

ExecReScan(node)
{
    node->plan->vtable->ReScan(node);
...

--------


-- 
Itagaki Takahiro

Attachment: extensible_execnodes-20101025.patch.gz
Description: application/x-gzip (12.0 KB)

Responses

pgsql-hackers by date

Next:From: Shigeru HANADADate: 2010-10-25 11:45:25
Subject: SQL/MED with simple wrappers
Previous:From: Heikki LinnakangasDate: 2010-10-25 08:17:10
Subject: Re: Range Types, discrete and/or continuous

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group