Hi all, 2014/1/14 Shigeru Hanada <shigeru.han...@gmail.com>: > I'd like to revisit this feature.
Attached patch allows a foreign table to be a child of a table. It also allows foreign tables to have CHECK constraints. These changes provide us a chance to propagate query load to multiple servers via constraint exclusion. If FDW supports async operation against remote server, parallel processing (not stable but read-only case would be find) can be achieved, though overhead of FDW mechanism is still there. Though this would be debatable, in current implementation, constraints defined on a foreign table (now only NOT NULL and CHECK are supported) are not enforced during INSERT or UPDATE executed against foreign tables. This means that retrieved data might violates the constraints defined on local side. This is debatable issue because integrity of data is important for DBMS, but in the first cut, it is just documented as a note. Because I don't see practical case to have a foreign table as a parent, and it avoid a problem about recursive ALTER TABLE operation, foreign tables can't be a parent. An example of such problem is adding constraint which is not unsupported for foreign tables to the parent of foreign table. Propagated operation can be applied to ordinary tables in the inheritance tree, but can't be to foreign tables. If we allow foreign tables to be parent, it's difficult to process ordinary tables below foreign tables in current traffic cop mechanism. For other commands recursively processed such as ANALYZE, foreign tables in the leaf of inheritance tree are ignored. Any comments or questions are welcome. -- Shigeru HANADA
Description: Binary data
-- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers