Re: Theoretical Basis for SELECT FOR UPDATE

vc wrote:
> Yes, that's possible at the expense of forcing all the potentially
> concurrent transactions modifying a common set of rows execute
> serially. The price of doing so is rather high.

I never said it wasn't. I merely said it was possible. Mind you, I have a feeling that serialisation would be required even with MV - i.e. SELECT FOR UPDATE to get the "before" data to be used in the statement.  We can't have data on which the statement relies changing under its feet, can we?

> I do not know what you'd suggested by saying "DB2 et al already have
> something like that". I decided, incorrectly, that "something like
> that" meant some form of multiversioning.

You don't always read carefully, do you? ;) I said: "More or less maybe, but you DON'T need the full works of multi-versioning just to store data temporarily; you just need a TEMP data area or enough memory. I imagine DB2 et al already have something like that?"

It seems clear to me that by "that" I meant "a TEMP data area or enough memory".

> > Anyway, this is all rather moot because the TTM's model for multiple
> > assignment is not intended to be implemented in DB2 or any other SQL
> > DBMS...
>
> Well, it's surely intended to be implemented somehow is not it, so we
> can at least speculate on how it might be implemented.

Sure, speculate away. DB2 can introduce multi-versioning to do it, or it can do it by alternative means but possibly less efficiently. Received on Thu Oct 06 2005 - 15:31:33 CEST