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.