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

Re: patch: SQL/MED(FDW) DDL

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: 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 02:29:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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?

> 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.


In response to


pgsql-hackers by date

Next:From: Darren DuncanDate: 2010-10-01 03:03:21
Subject: Re: O_DSYNC broken on MacOS X?
Previous:From: Robert HaasDate: 2010-10-01 02:23:30
Subject: Re: security hook on table creation

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