为了定义一个项目列表来分配给后缀中的许多不同选项，您可以使用逗号分隔的列表，如下所示：
relay_domains = example.com,example.net,example.org
或者像这样的哈希图：
relay_domains = hash:/etc/postfix/relay_domains
然后使用 postmap 将该键、值项文件转换为 bdb 文件。
我的问题是：使用哈希映射而不是仅指定列表是否存在性能原因？
答案1
我没有数据或指标来决定这两种情况下的性能是否重要。我将尝试解释涉及这两种情况的后台进程。
当 postfix 守护进程运行时，两者之间几乎没有区别，因为：
- 使用时
main.cf，postfix 会解析配置文件，将其保存到内存中，并且直到 postfix 重新启动或管理员发出命令时才会再次检查该文件postfix reload。 - 使用哈希表时，postfix 会解析表，将其保存到内存中并定期检查文件是否已更改。如果数据库已更改，postfix 将在处理下一个客户端请求之前终止，以便新进程可以使用新数据库进行初始化。来源
现在，如果你想更改列表，那么
- 更改后
main.cf，应调用postfix reload。它将强制主守护进程重新读取配置文件并终止子进程，以便它可以获取新配置。来源 - 更改哈希表后，无需调用
postfix reload。
我仍然不明白（1）通过手动调用重新启动子进程postfix reload和（2）通过哈希表触发重新启动子进程之间的区别已被修改。
阅读后的一些知识Postfix 手册页，尤其是守护进程部分。这有助于我理解 (1) 通过手动调用重新启动子进程和 (2) 通过哈希表触发重新启动子进程之间的区别postfix reload已被修改。
Postfix 的主进程名为掌握。它首次调用并充当“主”程序。它根据需要调用其他守护进程，例如 smtpd、qmgr、trivial-rewrite。
有四种类型的 Postfix 守护进程
- 守护进程不会死，因此它不会自动获取对 main.cf 的更改。
postfix reload配置更改后调用将使进程重新读取它。这包括：掌握。 - 成为持久进程的守护进程，因此它不会自动获取对 main.cf 的更改。
postfix reload配置更改后调用将使进程重新读取它。这包括：管理者，管理员，核实。 - 长时间运行的进程可以运行一小时到几个小时。
postfix reload配置更改后调用将加快配置更改速度。这包括：简单重写，捡起，后筛选，代理映射 - 短运行进程，只运行有限的时间。调用
postfix reload是不必要的，因为进程在再次运行时会重新读取 main.cf。这包括简体中文:，邮件传输协议，当地的以及除上述三类之外的其他过程。
如果您使用main.cf存储列表但不调用postfix reload，那么
- 由于其寿命较短，守护进程类别 4 将在进程复活后立即拾取它。
- 第 3 类守护进程需要一些时间才能生效
- 守护进程类别 1 和 2 永远不会重新读取，
main.cf直到您调用postfix reload：
当您使用哈希表来存储列表并且您postmap编辑了文件时，那么
- 守护进程类别 2、3、4 将检测文件更改。因此无需执行 postfix 重新加载。
- 守护进程类别 1 没有哈希类型的参数值。因此，它对主守护进程没有影响。
结论
否则，看起来上述两种情况之间的性能差异很小。如果你很少更改表，那么差异可以忽略不计。例外情况是，如果你经常执行postfix reload或更改哈希表，那么这将在qmgr过程中引起性能问题。参见这里和这里
更多信息：Postfix 性能自述文件