Kjell, > > I would hope that the new approach would takes 2X natural scan. > > > > How would that performance be? > > > > What new approach are you referring to?
<SL> The approach I was thinking about suggesting. > 2 X time for natural scan would be fair enough. It took 1½ hour to execute an > update using execute block with for select .... do update.... > where the select picked PK:s from a temporary table I filled with a select > like > the above. <SL> This is the basic approach I was going to suggest. <SL> Where I think there might be some optimization possible is to use a 'simple' UPDATE statement with WHERE EXISTS references to the temporary table keys (forcing the UPDATE WHERE to use a natural scan of your "large table") <SL> I think that SELECT ... DO UPDATE approach is generating some overhead, which the simple UPDATE would not have since it would be doing a in place update of the row at the cursor position. <SL> Come to think of it, you could also try modify your current solution to use a CURSOR approach, since the UPDATE would also be in-place.
