Re: SQL/MED estimated time of arrival?

From: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
To: Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)jp>
Cc: Eric Davies <eric(at)barrodale(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SQL/MED estimated time of arrival?
Date: 2010-11-15 03:56:59
Message-ID: AANLkTikS5iEFan3BpMASut6hmmpwDkuu3ec1i1bUyPLi@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 15, 2010 at 12:41, Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)jp> wrote:
> No, SQL/MED would not support indexing foreign tables, at least in
> first version.  Because it would be difficult to use common row id for
> various FDWs.

I think the reason is the SQL standard never mention about indexes.
It is not a specific issue for SQL/MED.

> To support indexing foreign tables might need to change
> common structure of index tuple to be able to hold virtual row-id, not
> ItemPointerData.

I'm not sure we actually need foreign indexes because the query text
sent to another server is same whether the foreign table has indexes.
Of course, foreign indexes might be useful to calculate costs to scan
foreign tables, but the cost also comes from non-index conditions.

I think foreign table and foreign index are a model for row-based
databases, including postgres. But other DBs might have different
cost models. So, it would be better to encapsulate such operations in FDW.

--
Itagaki Takahiro

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-11-15 04:39:33 changing MyDatabaseId
Previous Message Shigeru HANADA 2010-11-15 03:41:27 Re: SQL/MED estimated time of arrival?