> > Not at all, for now I've just modified db.c and db_add_quotum_used to > > check if the user_idnr==1, if yes, then it just returns w/o doing anything > > else. > > 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. 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. ----- "Mr. President, is it true you're only interested in Iraq for Oil?" "Oil? Who said anything about oil? Somebody cookin'?" - Black Bush [EMAIL PROTECTED]
