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:
>> - 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 Duncan||Date: 2010-10-01 03:03:21|
|Subject: Re: O_DSYNC broken on MacOS X?|
|Previous:||From: Robert Haas||Date: 2010-10-01 02:23:30|
|Subject: Re: security hook on table creation|