From: | David Fetter <david(at)fetter(dot)org> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, SAKAMOTO Masahiko <sakamoto(dot)masahiko(at)oss(dot)ntt(dot)co(dot)jp>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, 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-10-01 14:27:25 |
Message-ID: | 20101001142725.GB6319@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Sep 30, 2010 at 10:29:56PM -0400, Robert Haas wrote:
> On Sep 29, 2010, at 10:09 AM, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> > Excerpts from Robert Haas's message of mar sep 28 10:26:54 -0400 2010:
> >
> >> Then:
> >>
> >> - Begin a sequential scan with the following set of quals.
> >> - Begin an index scan using the index called X with the following set of quals.
> >> - Fetch next tuple.
> >> - End scan.
> >
> > 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; the remote executor would be in charge of determining
> > their usage for indexscans; or even for filtering tuples with
> > quals that cannot be part of the index condition.
>
> Yeah, that might be better. Is it reasonable to assume we always
> want to push down as much as possible, or do we need to think about
> local work vs. remote work trade-offs?
In cases where the foreign side is not super reliable for correctness,
I'd say there's a good case for not trusting it. Some of the Oracle
properties are like this. I suppose we might want to make "trust the
other side to handle pushed quals" optional somehow, but I'm not
exactly sure how.
> > There doesn't to be much point in knowing the names of remote
> > indexes either (if it came to referencing them, better use OIDs)
>
> Well, you can't assume the remote side is PG.
Very definitely not.
The main point of the feature is that it allows for *heterogeneous*
data stores. Of course this doesn't prevent PostgreSQL from
optimizing aggressively using secret knowledge should the "foreign"
side happen to be PostgreSQL.
Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-10-01 14:36:42 | Re: Patch author name on commitfest page |
Previous Message | Magnus Hagander | 2010-10-01 14:26:28 | Re: PG-Git usernames |