From: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, SAKAMOTO Masahiko <sakamoto(dot)masahiko(at)oss(dot)ntt(dot)co(dot)jp>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: patch: SQL/MED(FDW) DDL |
Date: | 2010-09-30 01:30:35 |
Message-ID: | AANLkTi=dXAzCm8+R03gzkCd_8FJ+9njW_Gj6wHujx3r9@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Sep 29, 2010 at 11:09 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | KaiGai Kohei | 2010-09-30 02:18:08 | Re: security hook on table creation |
Previous Message | Robert Haas | 2010-09-30 01:28:32 | Re: security hook on table creation |