> -----Original Message----- > From: David F. Skoll [mailto:d...@roaringpenguin.com] > > On Wed, 3 Aug 2011 21:15:16 +0200 > "Giampaolo Tomassoni" <giampa...@tomassoni.biz> wrote: > > > > Except that in real life, the write transaction lasts much longer, > > What is it? 60ms? Granted. It is still a 1/100 of 6s. > > No, write transactions are expensive because they (should) invoke > a fsync() system call. On a system with several contending processes > and busy disks, that can take hundreds of milliseconds or more.
I think this is OT here. However, since I like to win the last speech, my reply is that they hopefully don't necessarily involve an fsync: most modern databases use some kind of logging to store and write-back committed units-of-work. It is the write-back pump which drains committed units from the logging file, writes them and eventually invokes fsync. All the logging mechanism is exactly meant to defer the costs inherent to consistency by moving them outside the write path of transactions. I'm sure MySQL's InnoDB does log commitments... > Again, I'm speaking from experience here. I'm not just theorizing. > > > Ok. Let me see where in the code you see the transaction is completed > > soon after the token scores are fetched. > > I'm not familiar enough with the SpamAssassin code to go searching > (nor do I care since we use neither SQL nor SA for Bayes.) > > I don't see any commits in the read path, however. If MySQL > automatically opens a transaction whenever you do a SELECT, > then yes... that could be a problem. Aha! ;) Let see what thinks about this the author/maintainer of that code... Regards, Giampaolo > > Regards, > > David.
