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

Re: foreign data wrappers

From: Zheng Yang <zhengyang4k(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Shiv <rama(dot)theone(at)gmail(dot)com>, Selena Deckelmann <selena(at)chesnok(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Guillaume Lelarge <guillaume(at)lelarge(dot)info>, pgsql-students <pgsql-students(at)postgresql(dot)org>
Subject: Re: foreign data wrappers
Date: 2011-03-29 11:28:57
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-students
Hi guys,

>> I've briefly gone through the slides. Regarding the 6 callbacks, is that correct to say that a full table scan will always be performed irregardless of the sql statement,
>> the FDW is blind to the sql query performed, right?
> Yes, fairly much. If the feed is large you need some way to pass a limit to the foreign side, possibly via table options. I'm fairly sure you won't be able to get it via the SELECT statement.

Regarding the previous flickr example, I'm wondering how this 'free text search' function can be done if the FDW is blind to the SELECT statement.

For instance, the following query is to retrieve a photo relevant to 'panda':

	SELECT photo FROM flickr_table WHERE search LIKE '%panda%';

In this case, the FDW can only open a connection to flickr web service and return the next 'row' . 
The problem is that there are a huge number of photos in flickr server and retrieving them sequentially is not realistic. 
Any ideas on how this can be done?


In response to


pgsql-students by date

Next:From: Guillaume LelargeDate: 2011-03-29 15:48:53
Subject: Re: foreign data wrappers
Previous:From: Zheng YangDate: 2011-03-28 09:49:59
Subject: Re: foreign data wrappers

pgsql-general by date

Next:From: tushar neheteDate: 2011-03-29 11:35:04
Subject: Re: Autocommit off - commits/rollbacks
Previous:From: Jerry SieversDate: 2011-03-29 07:24:06
Subject: Re: Autocommit off - commits/rollbacks

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