Re: patch: SQL/MED(FDW) DDL
Itagaki Takahiro <itagaki.takahiro@gmail.com>
From: Itagaki Takahiro <itagaki.takahiro@gmail.com>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Robert Haas <robertmhaas@gmail.com>, SAKAMOTO Masahiko <sakamoto.masahiko@oss.ntt.co.jp>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2010-09-30T01:30:35Z
Lists: pgsql-hackers
On Wed, Sep 29, 2010 at 11:09 PM, Alvaro Herrera <alvherre@commandprompt.com> wrote: > I'm not sure that it's a good idea to embed into the FDW API the set of > operations known to the executor. For example your proposal fails to > consider bitmap scans. Seems simpler and more general to hand the quals > over saying "I need to scan this relation with these quals", and have it > return an opaque iterable object; Agreed. If possible, we will avoid dedicated interfaces for seqscans and index scans. However, bitmap scan is difficult anyway because foreign tables might not have ctid columns. It's a challenging task to identify individual tuples in foreign tables. It will be also used for UPDATE and DELETE. > There doesn't to be much point in knowing the names of remote indexes > either (if it came to referencing them, better use OIDs) FYI, HiRDB, that implements FDW routines, has CREATE FOREIGN INDEX. I think it is a little ugly and won't work in some cases -- for example, index organized tables -- but evidently it's a realistic solution. -- Itagaki Takahiro