Skip site navigation (1) Skip section navigation (2)

Re: patch: SQL/MED(FDW) DDL

From: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, SAKAMOTO Masahiko <sakamoto(dot)masahiko(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: patch: SQL/MED(FDW) DDL
Date: 2010-09-24 09:56:04
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Sep 24, 2010 at 6:12 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)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

In response to


pgsql-hackers by date

Next:From: Vlad ArkhipovDate: 2010-09-24 10:02:21
Subject: Name column
Previous:From: Heikki LinnakangasDate: 2010-09-24 09:12:38
Subject: Re: patch: SQL/MED(FDW) DDL

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group