On 04/25/2011 11:26 AM, Paul J Stevens wrote: > Being 'pretty safe' was deemed unacceptable at the time. Odds for > running into collisions were significantly less than astronomical when > taking into account the http://en.wikipedia.org/wiki/Birthday_attack. > > However, since this is basically a policy decision, it would we quite > feasible make this algorithm a runtime configuration - allowing system > administrators to select either the strict policy now in use, or a more > relaxed and faster policy where blob=? is dropped. > Could you not make it 2-stage, and then configurable as to whether to do split query or not?
Basically have both queries. Only if the first succeeds do you check the
second.
Kinda like this:
if("SELECT 1 FROM dbmail_mimeparts WHERE hash=? AND size=? LIMIT 1") {
if("SELECT id FROM dbmail_mimeparts WHERE hash=? AND size=? AND
blob=?") {
}
}
It would admittedly make the case where there is a legitimate collision
(legitimate as in, this _really_ is the same blob) slower. I don't know if this
is a particular problem or not. The case of the second query failing (but the
first succeeded) should be a degenerate case.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
