首先

最近有很多将RDBMS开源化的趋势，是不是如此？

当然地，由于没有经济上的困扰，我想介绍一些在使用OSSDB时可能会遇到的困难。

希望我的信息能成为考虑引入的人们的参考。

尽管是相同的查询，但是…

最初使我困惑的是同样的查询却有着巨大的执行时间差异。

因为是不同的DBMS，所以执行计划的构建和内部缓存机制完全不同，这可能是导致这种情况的原因。
实际上，在商业数据库中，经常会出现在OSSDB中执行的过程无论等多久都无法结束的情况，因此商业数据库可能已经对此进行了”不错的处理”。
在处理OSSDB时，需要学习以前不会关注的计划器/优化器的理解和执行计划的方法。

吸尘器？那是什么东西？

这可能也是PostgreSQL特有的思维方式。
请详细参阅官方文档，但是为了清理和回收在更新和删除时产生的垃圾，需要有一个机制来冻结和回收。
最近，由于自动清理（auto vacuum）已默认启用，通常不需要太过担心，但是频繁进行清理会导致性能下降，因此需要进行参数调整。

当然，并不仅仅是随意调整参数就可以的，需要在理解每个参数的意义以及其对哪些方面造成影响的基础上，根据数据量和更新频率来设置适当的值。

另一方面，如果数据量和更新量并不大，并且对性能有一定的容忍度，那么就没有必要太过担心。

而且，通过扩展功能可以解决这种烦恼，因此需要进行信息收集。

有过使用经历的人——场景

希望我们公司内有先驱者存在，但可能对这篇文章感兴趣的人恰好就是贵公司的先驱者吧。
我困扰的事情基本上是需要自己仔细研究和开拓许多官方文件。
在这种情况下，加入用户会等成为社区的一员，可能会有人可以作为咨询对象，这也许是一个好主意。

在中国母语中的释义：利用系统功能

在高级商用数据库中，通常会每月重新创建索引，并且拥有复制、维护和运营功能。当然，并没有像这样的数据库存在（或者可能在扩展中存在，但我不了解）。虽然复制可以在配置后自动运行，但如果需要定期执行REINDEX等操作，则需要与调度程序结合使用。

哎呀？数据库无法跨越吗？

根据DBMS的类型而定，无法在查询中指定数据库。

熟悉跨数据库查询的人可能会觉得非常麻烦。
但是有一个名为postgres_fdw的扩展可以实现跨数据库操作，通过使用它可以实现这一目标。但需要额外学习一些使用方法。

结束

现在已经习惯了，但刚开始变化时确实有些困难。

在我进行各种调查的过程中，我渐渐想要变得更加详细，并且我认为我已经获得了一定程度的知识。
前几天我还参加了PostgreSQL Conference，但是我发现还有很多更深入的应用实例需要学习。