我tds_fdw在 MS SQL Server 和 PostgreSQL 之间使用过。

我在 PostgreSql 中创建了一个外部服务器和外部表。当我从外部表中选择数据时，它也会运行 Mssql？还是 PostgreSQL 中的数据存储？

当我在 PostgreSQL 中查询我在 from 子句和 where 子句中使用了相同的外部表时，我得到了超时错误。而如果我删除 where 子句并将其添加为 cte，它会在不到一秒的时间内执行。请告知此外部表是否有查询限制。

我有 3 个运行 PostgreSQL 数据库的独立 ruby​​ on rails 应用程序，它们都具有相同的表（和列）但值不同。

例如 ：

应用程序 1 表

应用 2 表

应用程序 3 表

我希望从两个数据库中导出/转储/下载并导入到一个统一数据库/应用程序中。

如果有人可以为我指出正确的方向/阅读此类查询，我将不胜感激。

我在 Oracle 中有一个 OLTP 数据库，在本地 PostgreSQL 中有一个下游 OLAP 系统。使用 Oracle_FDW 将来自 Oracle 的数据泵入 PostgreSQL。

我正在探索将 PostgreSQL 迁移到 AWS 的可能性，但没有一个 RDS 具有 Oracle_fdw 功能。一种出路是在 EC2 实例上安装 PG，但这会保留 AWS 原生提供的一些功能，例如只读副本。有更好的解决方法吗？

还有一种方法可以从 AWS 中的 Postgres RDS 中获取 Oracle RDS 中的数据吗？

我正在从本地客户端对远程 Postgres 实例运行以下查询：

matches_tb1是一个外部表，具有match_id唯一索引。查询似乎永远挂起。当我使用explain verbose时，没有ORDER BY附加到“远程 SQL”。我猜本地服务器没有将订单下推到远程服务器。我该如何解决这个问题？

附上解释结果：

我有许多由以下方式导入的外部表IMPORT FOREIGN SCHEMA：

我有很多查询加入我的本地表和外部表。

Q1：如果我使用pg_prewarm并将整个表放在内存中，它不会帮助我每次都通过网络获取这张表。

Q2：如果外部表被缓存，我担心外部 PostgreSQL 服务器上的数据更改是否会在我的本地服务器上可见。

示例：core_category是一个外部表

我有一组应用程序访问同一服务器上的两个不同的 PostgreSQL 9.6 数据库。由于某些应用程序限制，一个应用程序通过一个数据库中的 FDW 访问少数表到另一个数据库。

像这样的东西：
DB1.fdw_table_a->DB2.table_a

fdw_table_a仅用于插入日志数据。这个表有一个id列，它是一个bigint序列。该序列存在于 DB1（在外部表上）和 DB2（“真实”表）中。这可以正常工作，一切都很好。

现在需要让另一个应用程序（同样具有有限的访问能力）对“真实”表执行插入操作，DB2.table_a. 在测试中，我可以看到id列中有一些不一致的地方，但没有出现明显的问题。

我可以在面向客户的环境中看到 DB1 FDW 序列按预期使用，但是当插入直接在 DB2“真实”表上开始时，该序列将从 1 开始（因为它从未被使用过）。

在这种环境下，我们还应该考虑其他事情吗？插入表格的这两个序列的重叠是否会出现一些问题？

我有两个数据库 db1 和 db2.db2 有外部表，比如 tableA，其模式已从 db1 导入。每次更新行都会在 db1 中的 tableA 上运行一个触发器。现在使用 postgres_fdw 我可以从 db2 获取记录，但由于该触发器功能而无法更新 tableA 上的任何记录。如果我禁用触发器，更新工作正常。我需要该触发器用于审计日志。

请给我一个合适的建议来解决这个问题。我使用的是 postgres 9.6。

设置

• 使用 Django Rest Framework (DRF) 设置的 PostgreSQL 10.6 数据库，最终将接管遗留系统。包含数亿行。
• 具有旧架构的单个 PostgreSQL 10.6 远程实例。

任务

在合理的时间（分钟）内将旧数据库中的数据导入 Django 数据库，以便可以在 CI 运行期间完成此任务。

工作至今

我们首先创建了一个单独的 Python 脚本来使用 Django API 来导入数据。团队知道这会很慢，但我们想测试 API 并最终得到一些有用的反馈。在我们的开发环境中（在 VM 中），这最终可能每秒创建几十行。

我们现在要导入更多数据。我们首先将脚本移动到 Django 管理命令中，以便我们可以直接实例化 DRF 序列化程序，而不是调用 API。这有点快。

然后我们尝试用 实例化 DRF 序列化程序many=True，但这并没有明显更快。

当前最快的实现可能每秒导入 80-100 行，所以我们决定改变策略。导入器经过全面测试，因此我们决定尝试使用外部数据包装器来使用原始 SQL 导入数据，从其中一个小表开始。生成的 Python 代码如下所示（为了便于阅读而删减）：

在 PostgreSQL shell 中手动运行此 SQL 工作正常：

问题

Python 代码挂在最后execute。此时遗留数据库中的状态如下：

在这一点SELECT pg_cancel_backend([pid])上没有做任何事情。在SELECT pg_terminate_backend([pid])Python 代码继续正常运行之后。此外，SELECT上面光标中的查询会立即返回，所以这不是一个简单的大小问题。

我还发现，上面START TRANSACTION的DECLARE语句在遗留数据库中运行得很好，所以我怀疑问题出在 Python 中。strace -f该命令显示了一个无限循环（每 20/30 秒重复一次），如下所示：

有趣的是，如果我创建带有名称的游标，我会得到一个非常不同的错误。例如，如果我创建第一个cursor(name='cd1')光标

为什么在为该查询创建/使用游标时 Python 会挂起？

使用来自 PyPI 的 psycopg2-binary 2.7.6.1。

看起来问题在于，当此代码运行时，已经直接建立了与旧数据库的另一个连接，因为当我避免它正确运行时。我会尝试解决这个问题，看看会发生什么。

我正在使用外部数据包装器将大量数据（在一列上进行非常简单的日期转换）移动到本地数据库。使用 Django 游标（因为我懒得拿出凭据来创建原始 psycopg2 游标）我进行了这种查询（匿名并删除了几个连接，但在其他方面与原始连接相同）：

但是，本地Postgres 服务器总是在一段时间后被 OOM 杀死。我期待 Postgres 将新行刷新到磁盘以避免内存不足，但据我所知，这并没有发生 -/var/lib/docker/volumes/vagrant_postgres_data仅增长几 MB，而常驻内存使用量增长到 GB。本地服务器没有足够的 RAM 将整个结果集保存在内存中，因此我需要一个不涉及更昂贵硬件设置的解决方案。

我需要设置类似的东西wal_sync_method还是work_mem让它工作？

根据文档executemany应该是适合这项工作的工具：

该函数对更新数据库的命令非常有用：查询返回的任何结果集都将被丢弃。

在 Linux 上的服务器上运行Postgres 10.6 容器，并在本地运行 Django 2.1。除了 FDW，我没有使用任何扩展。

解释计划：

postgresqltuner建议我

在 /etc/sysctl.conf 中设置 vm.overcommit_memory=2 ... 这将禁用内存过度使用并避免 postgresql 被 OOM 杀手杀死。

那是解决方案吗？