Re: Extensible executor nodes for preparation of SQL/MED

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Extensible executor nodes for preparation of SQL/MED
Date: 2010-10-25 15:28:16
Message-ID: 8577.1288020496@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2010-10-25 15:38:59 Re: Range Types, discrete and/or continuous
Previous Message Pavel Stehule 2010-10-25 15:27:48 Re: bug in explain - core dump