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 |
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? |