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 обсуждение исходный текст |
Ответ на | Re: Function scan push-down using SQL/MED syntax (Hitoshi Harada <umi.tanuki@gmail.com>) |
Ответы |
Re: Function scan push-down using SQL/MED syntax
|
Список | pgsql-cluster-hackers |
Hitoshi Harada <umi.tanuki@gmail.com> 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 по дате отправления: