Re: patch: SQL/MED(FDW) DDL - Mailing list pgsql-hackers

From Itagaki Takahiro
Subject Re: patch: SQL/MED(FDW) DDL
Date
Msg-id AANLkTimUT-mmgs-nez97=tw9SEhcijJBeQx7=+9VvB8B@mail.gmail.com
Whole thread Raw
In response to Re: patch: SQL/MED(FDW) DDL  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: patch: SQL/MED(FDW) DDL  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Fri, Sep 24, 2010 at 6:12 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> It's not that the design is bad, it's that it's non-existent. I haven't seen
> any design on how this integrates with the planner.

In my understanding, the DDL part is independent from planner integration,
and that's why the author extract DDL changes from the composite patch.
(The proposal name is "SQL/MED(FDW) DDL".)


I think there are two type of FDWs. One is a simple flat file wrapper
used by COPY FROM now, that doesn't require any planner hooks.
Another is a connector to an external database, like as dblink, that
should be integrated with the planner.

The former is almost same as SRF functions, but it will skip unneeded
tuplestore caching. Even the level is useful enough because we can
support "SELECT * FROM csvfile" without any intermediate tables.
Could we set the first goal to the level?

Of course we need more discussion for the latter case. The current proposed
patch ("select" part") supports  executor integration -- WHERE clause
push-down, so it can use indexes in external servers. On the other hand,
unsupported ORDER BY, LIMIT, and JOIN push-down require planner integration.
More works will be required for fdw_select20100917.patch.gz.

-- 
Itagaki Takahiro


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: patch: SQL/MED(FDW) DDL
Next
From: Vlad Arkhipov
Date:
Subject: Name column