Re: Original design approach to Oracle REDO Logs

Mark,

Don't forget the transformation would also have to cater for "column1 is null", because that should be updated too (unless the update were to set it to null).

But the problem is a "notable change in behaviour" - the no-change rows would not be locked.
I can't think of an example why this might be bad news in a well-designed and coded sysatem, but imagine:

user A:  update rows set ownership = 'USERA' where ...';
user B:  update rows set ownership = 'USERB' where ...;
user A:  update where ownership='USERA';
user B:  update where ownership='USERB'

> MWF wrote:
>
> “At the query level I wonder if permuting the query when it can be
> certainly iso-functional as
>
> update someTable
>
> set someColumn1 = 1.234
>
> becomes
>
> update someTable
>
> set someColumn1 = 1.234
>
> where someColumn1 != 1.234”
>
>
>
> I almost can’t believe I’m suggesting this; but is there a nugget of an
> “enhancement” request in there? I could see cases where if the optimizer
> was going to do an index lookup (i.e. there was a unique index on that
> column), OR, a full table scan (i.e. NO other path) a query rewrite might
> give some dramatic results (I think any paths other than “direct index” or
> full table scan would probably not be deterministic enough to “take a
> chance”).
>
>
>
> Clay Jackson
>
>
>

--
http://www.freelists.org/webpage/oracle-l