Ian G Batten
ian.batten at uk.fujitsu.com
Tue Nov 20 05:27:58 EST 2007
On 19 Nov 07, at 2139, Scott Adkins wrote:
> This does bring up an important point... we had to disable duplicate
> suppression on our server because it was just causing too much
> When every single mail message being delivered has to check against
> database, it is a problem.
The checking's not the problem, as the 99.9% case is an update. In
other words, if the rate of duplicates were high, you could lock it
for reading, check the message was unique, and then if that gave a
positive response lock it for update and perform the update. Yes,
there's a race condition, but it's small and benign.
However, in the real world this gains you nothing, because the rate
of duplicates is vanishingly small. You buy complexity and a race
condition for degraded performance (the lock upgrade is expensive).
There are other possible solutions. One would be a per-user, or per-
user-initial-letter, duplicate database. Another would be to not
bother syncing the database (I think this is what berkeley-nosync
does, but that doesn't help skiplist users).
More information about the Info-cyrus