Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 04F191337B69 for ; Tue, 29 Mar 2011 12:49:16 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 74085-06 for ; Tue, 29 Mar 2011 15:48:58 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sd-17937.dedibox.fr (sd-17937.dedibox.fr [88.191.100.74]) by mail.postgresql.org (Postfix) with ESMTP id 1E2B51337B67 for ; Tue, 29 Mar 2011 12:48:57 -0300 (ADT) Received: from [192.168.42.162] (LCaen-151-93-7-26.w80-13.abo.wanadoo.fr [80.13.230.26]) by sd-17937.dedibox.fr (Postfix) with ESMTPA id 7CA443B8F5; Tue, 29 Mar 2011 17:48:56 +0200 (CEST) Message-ID: <4D91FF65.2090401@lelarge.info> Date: Tue, 29 Mar 2011 17:48:53 +0200 From: Guillaume Lelarge User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Zheng Yang CC: Andrew Dunstan , Shiv , Selena Deckelmann , Alvaro Herrera , pgsql-students Subject: Re: foreign data wrappers References: <690867AB-C50B-4354-91D0-8A0811639C4C@gmail.com> <4D879CD0.5030803@dunslane.net> <3EF9E4CC-CF42-4B45-86FF-4CB9D46D7442@gmail.com> <4D8AF8C2.3000007@lelarge.info> <4ACC318A-1B6F-49A5-9B02-49EEAF7B97C7@gmail.com> <1300985156-sup-3058@alvh.no-ip.org> <47676.208.91.122.102.1300985713.squirrel@dunslane.net> <603812A0-F464-44AE-8A90-DF9BD1DC2DB9@gmail.com> <4D8E0125.9060905@dunslane.net> <8DB4D3E9-DA21-45FD-A2A2-5C6D479AA565@gmail.com> In-Reply-To: <8DB4D3E9-DA21-45FD-A2A2-5C6D479AA565@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.324 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_NJABL_PROXY=2.224 X-Spam-Level: X-Archive-Number: 201103/38 X-Sequence-Number: 179 Le 29/03/2011 13:28, Zheng Yang a écrit : > 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? > It probably means that flickr is not a good example of a nice fdw. -- Guillaume http://www.postgresql.fr http://dalibo.com