On May 9, 2009, at 5:53 AM, Paul McCullagh wrote:
As far as I know, the start time of a transaction is not significant.
Or do you maybe have an example of where this is the case?
If you focus on statement replication, then READ UNCOMMITTED would
possibly cause problems..
However, row based is the hot new thing, right? Row based replication
tells us which rows to update. Thinking about things in terms of rows
has made me think that we can actually do this w/o rolling back. Of
course, row based means it needs to be logged before knowing the
commit TX ID, but that is actually ok. We'll figure it out, and in the
process, we can figure out what ranges of IDs each transaction
modified. This will allow us to decide not to start transactions that
might modify the same rows as currently running transactions, thereby
achieving what Robert was suggesting, finding smaller slices than
"table" to parallelize on:
(T1) update foo set x=1 where id=1
(T2) update foo set x=2 where id=5
(T1) update foo set x=1 where id=5 (blocks)
(T2) commit (unblocks T1)
(T1) update foo set x=1 where id=100
(T1) update bar set z=9 where id=1
(T3) update foo set x=3 where id=50
(T3) update foo set x=3 where id=101
(T4) update foo set x=3 where id=100
(T1) commit
(T4) commit
(T3) commit
So, we start T1 and know that it changed row 1, so the range is 1:1 ,
then start looking forward for its commit id, all the while queueing
up T2-T4's row changes but not starting them. Then we find row 5
changed by T2. We keep track of its range too. Now we find that T2 is
committed. Next thing we find is that T1 has changed row 5. Its range
is now 1:5. Next we should find that it changed row 100, so now 1:100.
While T1 was updating table bar, T3 came along and modified id = 50.
This hits the range, so we queue it to start after T1 commits. We now
set T3's range to 50:101. T4 is queued for starting after T3, because
its range it fits inside that range. Now once T1 commits, T3 is run
and committed, then T4.
This means that some things that don't *have* to wait do wait.
However, I'm having a hard time imagining a situation where it starts
a transaction that might end up conflicting. And most of the time
we'll be able to start a lot of operations in parallel.
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
