Re: Function scan push-down using SQL/MED syntax

Поиск
Список
Период
Сортировка
Искать
От
Takahiro Itagaki
Тема
Re: Function scan push-down using SQL/MED syntax
Дата
Msg-id
20100308093153.9C38.52131E4D@oss.ntt.co.jp
Ответ на
Список
Дерево обсуждения
Function scan push-down using SQL/MED syntax Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>
Re: Function scan push-down using SQL/MED syntax Josh Berkus <josh@agliodbs.com>
Re: Function scan push-down using SQL/MED syntax Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>
Re: Function scan push-down using SQL/MED syntax Hitoshi Harada <umi.tanuki@gmail.com>
Re: Function scan push-down using SQL/MED syntax Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>
Re: Function scan push-down using SQL/MED syntax Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>
Re: Function scan push-down using SQL/MED syntax Hitoshi Harada <umi.tanuki@gmail.com>
Re: Function scan push-down using SQL/MED syntax Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>
Re: Function scan push-down using SQL/MED syntax Tatsuo Ishii <ishii@sraoss.co.jp>

Hitoshi Harada  wrote:

> I've not read any part of code yet but have comments:
> 
> * I'm not very happy with "Getting tuples from the foreign server"
> section. Present tuplestore isn't quite efficient and putting all
> tuples into TSS adds devastating overhead. In principle, storing
> tuples doesn't match SQL exectuor model. So something like cursor is
> needed here.

Sure, but your optimization requires some extensions in libpq protocol.
We could send HeapTuple in a binary form if the remote and the local
server uses the same format, but the present libpq can return tuples
only as text or libpq-specific binary forms (that is not a HeapTuple).

> * In FDW routines section there seems only methods to read out data,
> but I'd suggest there should be coverage of all CRUD operation.
> Sometimes dropping foreign data is so specific that only FdwRoutines
> know the way.

There is only SELECT in the SQL standard, where CREATE FOREIGN TABLE
means a symbolic link for the external data. But we also could support
CREATE and DROP in the routines, and it means CREATE/DROP FOREIGN TABLE
will actually create or drop external data.

Also, we could add methods for INSERT, UPDATE and DELETE -- but it
requires additional consideration that which key we should use to
determine the modified tuples; PostgreSQL uses CTID as a physical key,
but some of FDW might have completely different keys.

Regards,
---
Takahiro Itagaki
NTT Open Source Software Center


В списке pgsql-cluster-hackers по дате отправления
От: Tatsuo Ishii
Дата:
От: Takahiro Itagaki
Дата:
FAQ