Re: SQL/MED - core functionality

Поиск
Список
Период
Сортировка
От Shigeru HANADA
Тема Re: SQL/MED - core functionality
Дата
Msg-id 20101214001010.ACB2.6989961C@metrosystems.co.jp
обсуждение исходный текст
Ответ на Re: SQL/MED - core functionality  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: SQL/MED - core functionality  (Hitoshi Harada <umi.tanuki@gmail.com>)
Re: SQL/MED - core functionality  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Thu, 25 Nov 2010 15:03:29 +0200
Heikki Linnakangas <heikki.linnakangas@enterprisedb.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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: pg_archivecleanup should remove WAL files also in pg_xlog?
Следующее
От: Andres Freund
Дата:
Сообщение: Re: hstores in pl/python