On Mon, Nov 15, 2010 at 12:41, Shigeru HANADA <han...@metrosystems.co.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
