Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 81CB11337B5D for ; Fri, 1 Oct 2010 11:27:38 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 47458-04 for ; Fri, 1 Oct 2010 14:27:32 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from fetter.org (mail.fetter.org [64.81.66.25]) by mail.postgresql.org (Postfix) with ESMTP id 951E51337BA2 for ; Fri, 1 Oct 2010 11:27:25 -0300 (ADT) Received: by fetter.org (Postfix, from userid 500) id CF929FBCB39; Fri, 1 Oct 2010 07:27:25 -0700 (PDT) Date: Fri, 1 Oct 2010 07:27:25 -0700 From: David Fetter To: Robert Haas Cc: Alvaro Herrera , SAKAMOTO Masahiko , Itagaki Takahiro , Heikki Linnakangas , pgsql-hackers Subject: Re: patch: SQL/MED(FDW) DDL Message-ID: <20101001142725.GB6319@fetter.org> References: <4C9C6B86.3040102@enterprisedb.com> <4CA03EBA.4010203@oss.ntt.co.jp> <1285768919-sup-3750@alvh.no-ip.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-5 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201010/30 X-Sequence-Number: 171070 On Thu, Sep 30, 2010 at 10:29:56PM -0400, Robert Haas wrote: > On Sep 29, 2010, at 10:09 AM, Alvaro Herrera 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 http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.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