Clint's proposal would work very well for certain workloads. At a coarser level, it would be beneficial for some other workloads to do table-level dependency checking. This is a very old and well understood problem as far as I know (though I am not the expert on it myself) -- I remember studying this in chip architecture classes in college.
That is: if two transactions don't touch the same tables, they are fine to run concurrently, in any order. Or even if they do -- as long as they're only reading from the shared tables, they're fine to run concurrently. It's all a question of read-after-write and write-after write and all that -- there are only four combinations. There are a lot of edge cases that I think would make this complicated. If the slave stops while it was applying several transactions, where should it start again? Maybe transaction 5 was finished, but 4 and 3 were halfway through and got rolled back. I expect a lot of similar nasties to rear their heads. (This particular one could be solved by executing parallel but commiting in the original order, of course.) Baron _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
