PostgreSQL 9.3.4 文档 | ||||
---|---|---|---|---|
Prev | Up | Appendix F. 额外提供的模块 | Next |
postgres_fdw模块提供了外部数据包装器postgres_fdw,它可以被用来访问存储在外部PostgreSQL服务器中的数据。
这个模块提供的功能大体上覆盖了较老的dblink模块的功能。但是postgres_fdw提供了更透明且更兼容标准的语法来访问远程表,并且可以在很多情况下给出更好的性能。
要使用postgres_fdw来为远程访问做准备:
使用CREATE EXTENSION来安装postgres_fdw扩展。
使用CREATE SERVER创建一个外部服务器对象,它用来表示你想连接的每一个远程数据库。指定除了user和password之外的连接信息作为该服务器对象的选项。
使用CREATE USER MAPPING创建一个用户映射,每一个用户映射都代表你想允许一个数据库用户访问一个外部服务器。指定远程用户名和口令作为用户映射的user和password选项。
为每一个你想访问的远程表使用CREATE FOREIGN TABLE创建一个外部表。外部表的列必须匹配被引用的远程表。但是,如果你在外部表对象的选项中指定了正确的远程名称,你可以使用不同于远程表的表名和/或列名。
现在你只需要从一个外部表SELECT来访问存储在它的底层的远程表中的数据。你也可以使用INSERT、UPDATE或DELETE修改远程表(当然,你在你的用户映射中已经指定的远程用户必须具有做这些事情的权限)。
我们通常推荐一个外部表的列被声明为与被引用的远程表列完全相同的数据类型和排序规则(如果可用)。尽管postgres_fdw目前已经能够容忍在需要时执行数据类型转换,但是当类型或排序规则不匹配时可能会发生奇怪的语义异常,因为远程服务器解释WHERE子句时可能会与本地服务器有所不同。
注意一个外部表可以被声明比底层的远程表较少的列,或者使用一种不同的列序。与远程表的列匹配是通过名字而不是位置进行的。
A foreign server using the 一个使用postgres_fdw外部数据包装器的外部服务器可以使用和libpq在连接字符串中能接受的选项,如Section 31.1.2所述,不过不允许这些选项:
user和password(反而,为一个用户映射指定这些)
client_encoding(这是自动从本地服务器编码设置)
fallback_application_name(总是设置为postgres_fdw)
只有超级用户可以在不经过口令认证的情况下连接到外部服务器,因此应总是为属于非超级用户的用户映射指定password选项。
这些选项可以被用来控制使用在被发送到远程PostgreSQL服务器的 SQL 语句中使用的名称。当一个外部表被使用不同于底层远程表的名称创建时,就需要这些选项。
这个选项给出用在远程服务器之上的外部表的模式名称,它可以为一个外部表指定。如果这个选项被忽略,该外部表的模式名称将被使用。
这个选项给出用在远程服务器上的外部表给出表名,它可以为一个外部表指定。如果这个选项被忽略,该外部表的名字将被使用。
这个选项给出用在远程服务器上列的列名,它可以为一个外部表的一个列指定。如果这个选项被忽略,该列的名字将被使用。
postgres_fdw通过在远程服务器上执行查询来检索远程数据,因此理想的扫描一个外部表的估计代价应该是在远程服务器上完成它的花销,外加一些通信开销。得到这样一个估计的最可靠的方法是询问远程服务器并加上一些通信开销 — 但是对于简单查询,不值得为获得一个代价估计而额外使用一次远程查询。因此postgres_fdw提供了下列选项来控制如何完成代价估计:
这个选项控制postgres_fdw是否发出EXPLAIN命令来获得代价估计,它可以为一个外部表或一个外部服务器指定。一个外部表的设置会覆盖它的服务器的任何设置,但是只用于这个表。默认值是false。
这个选项是一个要被加到那个服务器上所有外部表扫描的估计启动代价的数字值。这表示建立一个连接、在远端解析和规查询的额外负荷等。默认值是100。
这个选项是一个数字值,它被用作那个服务器上外部表扫描的每元组额外代价,它可以为一个外部服务器指定。这表示在服务器之间数据传输的额外负荷。你可以增加或减少这个数来反映到远程服务器更高或更低的网络延迟。默认值是0.01。
当use_remote_estimate为真时,postgres_fdw从远程服务器获得行计数和代价估计,然后在代价估计上加上fdw_startup_cost和fdw_tuple_cost。当use_remote_estimate为假时,postgres_fdw执行本地行计数和代价估计,并且接着在代价估计上加上fdw_startup_cost 和fdw_tuple_cost。这种本地估计不会很准确,除非有远程表统计数据的本地拷贝可用。在外部表上运行ANALYZE是更新本地统计数据的方法,这将执行远程表的一次扫描并接着计算和存储统计数据,就好像表在本地一样。保留本地统计数据可能是一种有用的方法来减少一个远程表的预查询规划负荷 — 但是如果远程表被频繁更新,本地统计数据将很快就被废弃。
默认情况下,所有使用postgres_fdw的外部表都被假定是可更新的。这可以使用下列选项覆盖:
这个选项控制postgres_fdw是否允许外部表被使用INSERT、UPDATE和DELETE命令更新。它可以为一个外部表或一个外部服务器指定。一个表级选项会覆盖一个服务器级选项。默认值是true。
当然,如果远程表实际上并非可更新的,将产生一个错误。这个选项的使用主要是允许在不查询远程服务器的情况下在本地抛出错误。但是要注意information_schema视图会根据这个选项的设置报告一个postgres_fdw外部表是可更新的(或者不可更新),而不需要远程服务器的任何检查。
postgres_fdw在第一个使用关联到外部服务器的外部表的查询期间建立一个到外部服务器的连接。这个连接会被保持,并被重用于同一个会话中的后续查询。但是,如果使用了多个用户实体(用户映射)来访问外部服务器,会为每一个用户映射建立一个连接。
在一个引用外部服务器上任何远程表的查询期间,如果还没有根据当前的本地事务打开一个远程事务,postgres_fdw将在远程服务器上打开一个事务。当本地事务提交或中止时,远程事务也被提交或中止。保存点也相似地采用创建相应的远程保存点来管理。
当本地事务为SERIALIZABLE隔离级别时,远程事务使用SERIALIZABLE隔离级别;否则它使用REPEATABLE READ隔离级别。如果一个查询在远程服务器上执行多个表查询,这种选择保证它将为所有扫描得到快照一致的结果。一种后果是在单一事务中的后继查询将会看到来自远程服务器的相同数据,即便由于其他活动在远程服务器上发生了其他并发更新。如果本地事务使用SERIALIZABLE或REPEATABLE READ隔离级别,这种行为也是可以预期的,但是对于一个READ COMMITTED本地事务它是奇怪的。一个未来的PostgreSQL发布可能会修改这些规则。
postgres_fdw尝试优化远程查询来减少从外部服务器传来的数据量。这可以通过把查询的WHERE子句发送给远程服务器执行来完成,并且还可以不检索当前查询不需要的表列。要减少查询错误执行的风险,除非WHERE子句中只使用内建数据类型、操作符和函数,它不会被发送给远程服务器。子句中的操作符和函数也必须是IMMUTABLE。
实际被发送到远程服务器执行的查询可以使用EXPLAIN VERBOSE来检查。
postgres_fdw能够与最老是PostgreSQL 8.3 的远程服务器一起使用。只读能力则最低可以在 8.1 中使用。但是一个限制是postgres_fdw通常假定不变的内建函数和操作符是安全的,如果它们出现在一个外部表的WHERE子句中,它们可以发送给远程服务器执行。因此,由于一个由于远程服务器的发布可能被发送给它来执行而被增加的内建函数,会导致"function does not exist"或一个类似的错误。这类错误可以通过重写查询来解决,例如通过嵌入在一个带OFFSET 0的子SELECT中引用的外部表作为一种优化墙,并且把出问题的函数或操作符放在子SELECT的外部。
Shigeru Hanada <shigeru.hanada@gmail.com>