Victor Duchovni:
> On Mon, Jun 08, 2009 at 02:10:29PM -0400, Wietse Venema wrote:
>
> > > /* qmgr_job_find - lookup job associated with named message and
> > > transport */
> > >
> > > /*
> > > * Instead of traversing the message job list, we use single per
> > > * transport hash table. This is better (at least with respect to
> > > memory
> > > * usage) than having single hash table (usually almost empty) for
> > > each
> > > * message.
> > > */
> > > return ((QMGR_JOB *) htable_find(transport->job_byname,
> > > message->queue_id));
> >
> > Which makes it tempting to work around the collision by tweaking
> > the index that is used for job lookup. For example, use binhash(3)
> > with the memory address of the message data structure as index.
> > That might be an option for past releases.
>
> Yes, that should do the trick.
>
> Mind you, the expected number of transports for a message is I think
> reasonably small.
I see one hash table that is indexed by the queue ID, so this
would involve one hash-table lookup per transport:
for each transport
if (htable_find(transport->job_byname, queue_id)
skip this message as a duplicate.
Wietse
> Why not just traverse the message job list (at most
> one job per-transport)? The cost of locating a hash slot, may be higher
> than chasing a couple of pointers and at most a few strcmp() calls,
> especially with a typical message having just one job (single recipient
> message).
>
> --
> Viktor.
>
> Disclaimer: off-list followups get on-list replies or get ignored.
> Please do not ignore the "Reply-To" header.
>
> To unsubscribe from the postfix-users list, visit
> http://www.postfix.org/lists.html or click the link below:
> <mailto:majord...@postfix.org?body=unsubscribe%20postfix-users>
>
> If my response solves your problem, the best way to thank me is to not
> send an "it worked, thanks" follow-up. If you must respond, please put
> "It worked, thanks" in the "Subject" so I can delete these quickly.
>
>
