Sumbry][ wrote:
It might be better to lookup the user_idnr for DBMAIL_DELIVERY_USER
(which is currently defined in pipe.c, but could be moved to db.h for
instance). You cannot count on DBMAIL_DELIVERY_USER having user_idnr '1'
always.
That makes sense. However, I'm more of a dba than a programmer and since
I'm not that familiar with dbmail internals yet I'd be more comfortable if
one of ya'll patched the sources.
I'll have a go at it then
As for now my little hack is working miracles. I'm a big beliver in the
80/20 rule (80 percent of your load is caused by 20 percent of your
queries/code) and in this case it was no exception.
Our postgres servers load has dropped at least 70 percent in the past 10
hours, and the load on our mail server (seperate from the sql server) has
eased up quite a bit too. I would definetely recommend not computing
quotas for at least the internal_delivery_user. I'd guess it's probably
still helpful to compute curmail_size for users with no maxmail setting
and the performance penalty wouldn't be that bad.
Those are impressive numbers! If you find more of these bottlenecks,
please mention them so we can try to fix them.
Ilja
