在
第一部分中，我们讨论了PostgreSQL 11的主要创新和变更。这一次，我们将更详细地讨论metup提出的问题/答案格式中的一些要点。
在PL / pgSQL中，将大型数据数组作为一组存储过程的输入参数传输的最佳方法是什么？
最方便的方法是创建一个临时表，在那里复制数据，然后在过程中使用它。
外部引擎（zheap）和内存中PostgreSQL的开发
并非对于所有工作负载，都适合在表本身中存储记录的旧版本的模型。 在所有其他subd（versionionniki）中，它们存储在撤消日志中。 您可以争论可行性，但最重要的是您需要将旧记录存储在某个地方。 如果它们的寿命很短，并且很少有人解决它们，那么将其存储在表中本身就是有害的。 外部zheap引擎PostgreSQL是EnterpriseDB尝试使用undo log为PostgreSQL创建表引擎的尝试。 尽管仍然有待改进，但它仍然有效。
与谁合作 处于SNAPSHOT隔离级别模式下的SQL知道它具有tempdb，可以放置旧版本，并且还具有清理tempdb的功能。 另一方面，社区要求在PostgreSQL中创建内存表。 这可以很容易地完成：tmpfs，仅此而已。 在PostgreSQL Pro甚至发布了第一个试用版中，您都可以尝试。
PostgreSQL从来没有过插件引擎。 有使用通用WAL的可插入索引。 PostgreSQL有很多需要插入的东西，很少有可以即时替换的东西。 例如，执行器未禁用，但是您可以在其中自己编写程序的自定义节点使用。 PostgreSQL中的优化器是完全可插入的。 您可以编写自己的数据库，并使用PostgreSQL作为查询的解释器。 SQL分析器无法连接。
引擎希望在三个方向建立连接：
Postgres Pro正在与EnterpriseDB讨论如何制作API以连接所有这些。
关于外键
PostgreSQL内部的外键由触发器实现。 您可以编写将实现任何功能的触发器。 必须在触发器中完成所有可能的限制。 触发器中的逻辑并不是特别必要，但要检查所有内容-这是必要的。
Postgres Pro是否计划使用SaaS或PaaS？
Postgres Pro计划使PostgreSQL更适合云计算，尤其是对共享缓冲区进行动态更改，以减少需要重新启动PostgreSQL的参数数量。 他们不会自己建立云。
如何设置驱动器，以便并行索引工作更快？ 多个硬盘或一个固态硬盘哪个更好？
更好一些SSD。 硬件提供的并行化选项越多越好。 如果您只有一个磁盘，没有足够的内存和一个处理器，那么并行化将无济于事。 但是SSD具有特殊性：如果超过80％的卷被占用，它们就会开始变慢。 因此，请不要忘记调整修剪，否则80％的限制将达到50％左右。
词典管理和全文搜索中添加单词
如果您使用拼写或滚雪球，则只需更改停用词词典。 麻烦在于，如果添加了停用词，那么索引编制就毫无意义。 这可以慢慢完成。 停用词将从请求中抛出，并且永远不会被搜索到。 而且，如果您删除了停用词，则集合中的任何地方都不存在停用词，您需要对其重新索引。 问题不在于字典，而在于您已经使用它并保存了知识。
同样，在许多情况下，您可以使用鲜为人知的函数ts_rewrite，该函数可让您用另一个请求替换一部分请求。 例如，当库尔斯克（Kursk）潜水艇被淹死时，每个人都急着寻找有关它的信息。 当时的Fedor Sigaev在漫步者中工作，并应“库尔斯克”的要求提供了有关这座城市的信息。 他们迅速做出了替换：在这个词上，给出有关潜艇的信息。 但是随后，用户开始对村庄本身感兴趣的诅咒。 我不知道他们是否意识到，但是有必要介绍“库尔斯克市”。 这样的替换允许进行ts_rewrite。 此外，该功能可用于在词典更改期间平稳过渡。
当然，更改解析器和字典是复杂的任务。 俄语和英语等不同字母的语言相处融洽。 如今，法英文本更加糟糕。 目前尚不清楚单词所指的语言，其书写方式相同，但在一种语言中是停用词，而在另一种语言中则不是。 Postgres Pro当前正在微调字典，以描述更复杂的配置。
涵盖索引和热更新
完全是朋友 的确，如果覆盖索引中至少更新了一个字段，则该索引将照常运行，所有内容将被替换。
在备用数据库上执行查询时无法创建临时表
PostgreSQL不在系统目录中存储表知识，但是有一个补丁可以将知识转移到系统目录中。 因此，通过此修补程序，您可以使用临时表。 但是，随之而来的另一个问题是：没有待处理的交易。 要使用临时表，您将必须使用两次虚拟事务ID，该ID仅适用于临时表，不适用于向导中的主要事务。 当您查看32位数字时，它们将是两个不同的数字。
Postgres Pro还具有pg_variables模块，该模块也可以在备用状态下工作。 这不是临时表，但是可以描述必要的功能。
实施集群索引
Postgres Pro曾多次尝试实现它。 现在，您可以输入集群表索引，并且表的顺序相同。 遭受了如何将表保持在群集状态的困扰。 我们尝试了不同的方法，但始终将其插入此类表非常昂贵。 这对任何人都没有兴趣。 因此，到目前为止，已经得出结论，有必要转向索引组织表。
推荐的自动真空比例系数
通常建议设置1-5％。 但这是完全可选的。 对于较小的表，尽管这些表平均有变化，但平均分布仍然相同，可以设置较大的值。 如果表很大且很少补充，但恰恰是在分配发生重大变化的情况下，您将不得不发明其他东西。 这完全取决于您的数据分布。
复杂查询的提示
在Oracle中，对于复杂的查询，您必须定期提供提示帮助，因为会发生突然的全面扫描。 Postgres Pro中有一些提示，虽然有些麻烦，但是您可以获取它们。 但是，常规PostgreSQL中没有任何提示，并且不太可能出现。 如果您具有内置的提示，则面对优化程序问题的用户将插入提示，冷静下来，并且不报告问题。 优化器开发停止。
顺便说一下，PostgreSQL优化器有问题。 当他从一个表中估计一个样本时，即使是或多或少合理的数量，他都可能会猜出一些错误。 然后它开始连接，结果连接到其他东西，错误累积，并且在第三或第四级PostgreSQL遗漏了很多东西。
有这样的设置-连接崩溃限制。 PostgreSQL对JOIN进行排序以便更有效地使用，但是默认的排序限制是8。如果连续有8个以上的JOIN，则系统将不对它们进行排序，并且查询中将依赖于JOIN顺序。
还有一个具有各种参数的遗传优化器。 您可以在会话中启用各种设置，或多或少描述应如何执行请求。 使用此顺序，借助方括号，您可以设置某些操作的关闭时间（秒扫描）。 另一种选择是将某些参数插入函数。 从某种意义上讲，这些也是提示。 不是很方便，但至少可以。