Re: SQL/MED - core functionality

From: Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)jp>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: SQL/MED - core functionality
Date: 2010-12-13 15:10:11
Message-ID: 20101214001010.ACB2.6989961C@metrosystems.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 25 Nov 2010 15:03:29 +0200
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> I propose the attached API instead. This has a clear separation between
> plan and execution. I'm sure we'll have to extend the API in the future
> FDWs want tighter integration, but I think this is a good start. It
> makes it quite straightforward to write simple FDW like the file FDW,
> without having to know anything about the executor or planner internals,
> but provides enough flexibility to cover the functionality in your
> PostgreSQL FDW.

Thanks for the comments and the proposal.

I've revised fdw_core patch along your proposal and subsequent
discussion, and tried to fix FDW patches pgsql_fdw and file_fdw
according to fdw_core. Attached is a WIP which includes changes
below.

(1) Introduce FdwPlan and FdwExecutionState
IIUC, FdwPlan should have copyObject support because it is a part of
Plan node and would be copied when the plan was cached. So FdwPlan
need to be a Node, and hold private information in List. In contrast,
FdwExecutionState.private doesn't have such limitation because it
would not be copied.

One problem to solve is that current PostgreSQL FDW needs PlanState to
generate foreign query string with deparse_expression(). It would be
able to generate SQL string from PlannerInfo and RelOptInfo in
PlanRelScan() without deparse_expression(), but it might need so many
codes.

(2) Pass ParamListInfo to BeginScan, not ForeignScanState
To handle parameters of EXECUTE statement, BeginScan need to get
ParamListInfo from EState. So I've added ParamListInfo parameter to
BeginScan.

(3) Iterate() returns result with TupleTableSlot parameter
How about receiving result with TupleTableSlot which was specified by
caller? This would allow FDWs to forget about ScanState. In this
design, the prototype of Iterate is:

void *(*Iterate)(FdwExecutionState *fstate, TupleTableSlot *slot);

(4) Support EXPLAIN information
Now EXPLAIN VERBOSE shows FDW-specific information. Here is a sample
of PostgreSQL FDW. File FDW might show filename and size.

postgres=# explain verbose select * From accounts where aid = 1;
QUERY PLAN
-----------------------------------------------------------------------------------------------------
Foreign Scan on local.accounts (cost=0.00..0.00 rows=1 width=100)
Output: aid, bid, abalance, filler
Filter: (accounts.aid = 1)
FDW-Info: SELECT aid, bid, abalance, filler FROM public.pgbench_accounts accounts WHERE (aid = 1)
(4 rows)

Regards,
--
Shigeru Hanada

Attachment Content-Type Size
fdw_core.patch.gz application/octet-stream 69.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2010-12-13 15:13:09 Re: hstores in pl/python
Previous Message Fujii Masao 2010-12-13 15:08:14 Re: pg_archivecleanup should remove WAL files also in pg_xlog?