On Tue, 2 Jul 2002, Phil Howard wrote:

> Just search ONE map, the one for the appropriate domain. Then we're
> doing 1*ln(n/x) ... times whatever it takes for the filesystem to
> find that map ... which makes it ln(n/x)+ln(x) ... or ln(max(n/x,x))
> as far as big-O is concerned.
>

To avoid running out of file descriptors this would need to be implemented
as a new (to Postfix) hierarchical map type. It will complicate chroot
setup, because the map hierarchy would need to be loopback (bind) mounted
into the chroot jain (always the Postfix queue directory). Additionally
the submaps for each domain would need to opened and closed on the fly,
with a suitable cache of open maps to avoid opening and closing maps for
every lookup. The underlying per domain map would need to be "cdb", not
Berkeleyu DB, since allocating and deallocating page pools and other map
open overhead in Berkeley DB potentially impacts lookup performance in a
negative way). What is the relative cost of map open vs. key lookup with
"cdb"?

Postfix maps do not know whether the lookup key is a user name, address,
domain name, ..., this happens at a higher layer accross all the map
types. Postfix maps just look up strings. Your map needs to parse its
keys into a domain and a user part. This conflicts with the Postfix
keyed map abstraction. Like "regexp" maps your map might need to avoid
"partial" keys so as not to get confused by source routes. There may be
other semantic subleties.

Actually LDAP maps with ldapsource_domain set also violate the abstraction
when filtering the input keys by domain, perhaps such maps should also
avoid "partial" keys.

Your proposal is a non-trivial development effort. Are you sure that your
energy and enthusiasm will be best spent in this direction? It would be
much easier to deploy something existing of the shelf even if slightly
imperfect the solutions will have been tested by others and known to work.

Of course all real progress is made by people who are wisely or otherwise
unhappy with the status quo, I do not want to discourage creativity, just
be aware that innovation is a risky business... :-(

-- 
	Viktor.
-
To unsubscribe, send mail to majordomopostfix.org with content
(not subject): unsubscribe postfix-users

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]