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

Re: patch: SQL/MED(FDW) DDL

From: Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)jp>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>,Alvaro Herrera <alvherre(at)commandprompt(dot)com>,Robert Haas <robertmhaas(at)gmail(dot)com>,SAKAMOTO Masahiko <sakamoto(dot)masahiko(at)oss(dot)ntt(dot)co(dot)jp>,pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: patch: SQL/MED(FDW) DDL
Date: 2010-09-30 07:48:36
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, 30 Sep 2010 09:26:54 +0300
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> > FYI, HiRDB, that implements FDW routines, has CREATE FOREIGN INDEX.
> > I think it is a little ugly and won't work in some cases -- for example,
> > index organized tables -- but evidently it's a realistic solution.
> A long time ago I used DB2's federated database feature, which is at 
> least close to SQL/MED if not fully compatible. When you create a 
> "federated index" there. it's just a planner hint to the local database, 
> so that it knows how expensive it is to evaluate a qual remotely vs. 
> locally. It shouldn't matter what technology the remote index uses in 
> that case, as long as the cost model is roughly the same as a b-tree.
> I don't think we want to go down that path though, it's better to leave 
> the cost estimation altogether to the wrapper. It has much better 
> knowledge of expensive various quals are.
> However, the wrapper will likely need some local storage for indexes and 
> like to do the cost estimation. Or maybe it can just keep the 
> information in cache, loading it on first use from the remote database.
How about having cost hints in generic option of the foreign table or
its columns?  Generic options are storage for wrappers, not for
PostgreSQL core modules.  Wrappers can use their own format to
represent various information, and use the hints to estimate costs of
a path.

In addition, I think that the generic option of a server could be used
to store cost hints which depend on each server, such as network
transfer overhead for dbms wrappers, or disk I/O for file-wrappers.

Shigeru Hanada

In response to


pgsql-hackers by date

Next:From: Pavel StehuleDate: 2010-09-30 08:02:14
Subject: wip: for-in-array patch
Previous:From: Dean RasheedDate: 2010-09-30 06:38:18
Subject: Re: WIP: Triggers on VIEWs

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