On Thursday 16 December 2010 15:11:01 Simon Riggs wrote:
> In order to remove X1 we would need to change X0 to point to X2, which
> we don't do because we're not allowed to update in place. Even if we
> could, I'm not sure this case is frequent enough to be worth the effort.
Especially as X3 would
On Wed, 2010-12-15 at 20:50 +0100, matteo durighetto wrote:
> if we continue the transaction and we do for example another update
> on this row (X) , we again redo the same operation:
>
>X0 (deleted "old" row)
>X1 (row inserted, NOW deleted) => not needed for rollback
>X2 (insert "
2010/12/15 matteo durighetto :
> But why we need all these versions of the same row on table, if for
> rollback we need only the original row X (X0) ?
And the "previous" value of row X during the execution of a statement
(because statements don't see their own changes, think INSERT INTO a
SELECT
On Wed, Dec 15, 2010 at 2:50 PM, matteo durighetto
wrote:
> Hi,
> I have an idea about mvcc and different DML of the same row in the
> same transaction.
> Normally when a backend do an unpdate on a row ( call it X ) , we done
> an insert and logical delete on this row (0,1,2..N are the "versio
Hi,
I have an idea about mvcc and different DML of the same row in the
same transaction.
Normally when a backend do an unpdate on a row ( call it X ) , we done
an insert and logical delete on this row (0,1,2..N are the "version
of the row) :
X0 (delete "old" row)
X1 (insert "new" row
