On Wed, Feb 22, 2012 at 09:17:24AM +0100, Angel L. Mateo wrote: > >Postfix is not monolithic, so cleanup(8) repeats some queries > >made by smtpd(8), and in smtpd(8) some queries are repeated because > >this makes the code more modular. > > I know it needs to repeat queries. But, in this case, why not > implementing a cache for such maps?
Additional complexity is not free, someone has to write, test and maintain the code. Code improvements are focused on useful outcomes. Optimization of non-critical paths is not sufficiently useful IMHO. > If I remember well in previous versions it did. There has never been a working LDAP query cache in the OpenLDAP library. Postfix support for the non-working query cache was withdrawn soon after the discovery that the OpenLDAP query cache was disfunctional and deprecated. Don't confuse caching of address verification probe results, or postscreen client test results, ... with caching of table lookup results. The former in fact use uncached table lookups. The latter cache information about the outside world (that is impossible or impractical to obtain with every lookup) not the result of a table lookup. Postfix has never had caching at the table-type driver level, and probably never should, such caching would cause plenty of WTF when table updates are not reflected in the behaviour of the MTA in a timely manner. People already complain from time to time about the tiny 1-element cache in the transport lookup code that is re-discovered from time to time in test environments when all mail is sent to a single address... There can be more caching in specific lookup contexts by various Postfix services, e.g. smtpd(8) could cache a few more lookups either for the lifetime of a client session, or LRU cache a small number of key/value tuples for a particular type of lookup for the server's lifetime. However, the cost-benefit analysis has to make sense. To reduce high query load, consider postscreen which typically eliminates a decent fraction of botnet SMTP sessions without performing any LDAP queries, ... just DNSBL lookups. In practice, the query load is very rarely high enough to give a well tuned LDAP or SQL server any trouble. -- Viktor.