postfix performance with lists in main.cf

Solution 1:

I don't have data or metric to decide if performance matter in both case. I'll try to explain what background process involving those two cases.

When postfix daemon was running, there is little difference between those two because:

• When using main.cf, postfix parses the configuration file, saves it to memory and doesn't check the file again until postfix restarted or administrator issues postfix reload command.
• When using hash table, postfix parses the table, save it to memory AND periodically check if file changed. If the database was changed, postfix will terminate before handling the next client request, so that a new process can initialize with the new database. ^source

Now, if you want to change the list, then

• After changing main.cf, you should invoke postfix reload. It'll force master daemon re-reads the configuration file and terminate the child process so it can pickup new configuration.^source
• After changing hash table, no need invoke postfix reload.

Still I don't understand the difference between (1) restarting child process by manually invokes postfix reload and (2) restarting child process triggered by hash table has been modified.

Here some knowledge after reading the postfix manuals page, especially on Daemons Process section. This help me understand the difference between (1) restarting child process by manually invokes postfix reload and (2) restarting child process triggered by hash table has been modified.

Postfix has the master process called master. It invoked for first time and serve as 'master' program. It invoked other daemon such as smtpd, qmgr, trivial-rewrite on demand.

There four kinds of postfix daemons

1. The daemon who won't die, so it won't automatically pick up changes to main.cf. Invoking postfix reload after a configuration change will make the process re-reads it. This including: master.
2. The daemon who became persistent process, so it won't automatically pick up changes to main.cf. Invoking postfix reload after a configuration change will make the process re-reads it. This including: qmgr, tlsmgr, verify.
3. The long running process who can run for range between one hour or several hours. Invoking postfix reload after a configuration change will speed up the configuration changing. This including: trivial-rewrite, pickup, postscreen, proxymap
4. The short running process who run for only a limited amount of time. Invoking postfix reload is unnecessary because the process re-reads main.cf when running again. This including smtp, smtpd, local and other processes beside three categorizes above.

If you are using main.cf to store the lists but not invoke postfix reload, then

• Daemons category 4 will pickup it immediately after process revival because of it short age.
• Daemons category 3 need some time to get the effect
• Daemons category 1 and 2 never re-reads main.cf until you invoke postfix reload:

When you are using hash table to store the lists and you postmap-ed the file, then

• Daemons category 2,3,4 will detect the file changes. So no need to do postfix reload.
• Daemon category 1 doesn't have hash-type parameter value. So, it has no effect to master daemon.

Conclusion

Otherwise, looks like the performance difference between two cases above was little. If you rarely change the table, then the difference can be neglected. The exception is if you frequently do postfix reload or change the hash table, then it will be performance concern in qmgr process. See here and here

Further info: Postfix Performance readme