Re: SQL/MED with simple wrappers
От | Pavel Stehule |
---|---|
Тема | Re: SQL/MED with simple wrappers |
Дата | |
Msg-id | AANLkTingUR2OEBdh3syXdfefdSm+RYt48iTYxSPY7TEs@mail.gmail.com обсуждение исходный текст |
Ответ на | SQL/MED with simple wrappers (Shigeru HANADA <hanada@metrosystems.co.jp>) |
Ответы |
Re: SQL/MED with simple wrappers
|
Список | pgsql-hackers |
Hello > 4) List of foreign connections > Users (especially DBAs?) might want to see list of foreign connections. > Currently postgresql_fdw provides its own connection list via > postgresql_fdw_connections view. Common view such as > pg_foreign_connections would be needed? If so, function which returns > list of active connections would be necessary in FDW API. > + list of foreign tables? > 5) Routine mapping > If a function in local query can be evaluated on the remote side in > same semantics, it seems efficient to push the function down to the > remote side. But how can we know whether the function can be pushed > down or not? For such purpose, SQL/MED standard defines "routine > mapping". Should we implement routine mapping? > is it related to aggregate functions? If yes, this it can be really significant help > > 7) Using cursor in postgresql_fdw > postgresql_fdw fetches all of the result tuples from the foreign > server in the first pgIterate() call. It could cause out-of-memory if > the result set was huge. If libpq supports protocol-level cursor, > postgresql_fdw will be able to divide result set into some sets and > lower the usage of memory. Or should we use declare implicit cursor > with DECLARE statement? One connection can be used by multiple > ForeignScan nodes in a local query alternately. An issue is that > cursor requires implicit transaction block. Is it OK to start > transaction automatically? I don't know why DECLARE statement is problem? Can you explain it, please. regards Pavel Stehule
В списке pgsql-hackers по дате отправления: