You mentioned above that your update is running within 45 seconds. It's unclear why this would be unacceptable. If you are updating this table multiple times per day, then you may want to rethink whatever it is you're doing. That amount of mass DML operations done on a routine basis will negatively impact your database, not just runtime, but also in terms of backups, I/O, and data fragmentation.

I'm assuming that the tables are properly indexed for the join, and the issue is that you're attempting to update a large number of rows.

Generally speaking, most of the duration spent for a large (100,000 rows or more) UPDATE or DELETE operation will be transaction logging. From what I've seen, and I have a lot of experience running massive updates against data warehouse tables, the duration required for writing to the transaction log increases exponentially (not linearly). If you are going to run an update operation that affects more than one million rows, then you would benefit from batch updating.

The following technique will yield better performance regardless of recovery model; simple, full, or bulk. You can cancel at any time, and any rows updated to that point are committed, so long as don't wrap the entire loop in a transaction.

set nocount on;

declare @batch_rows int = 0, @total_rows int = 0, @UpdateDate datetime = getdate();

while 1 = 1

begin

-- to minimize transaction log growth, checkpointing and pausing

-- each batch will help re-use space:

waitfor delay '00:00:05';

checkpoint;

-- update batch of rows:

update top (1000000) MyLargeTable

set Price = Price * 1.10

, UpdateDate = @UpdateDate

where UpdateDate is null or UpdateDate < @UpdateDate;

select @batch_rows = @@rowcount;

select @total_rows = @total_rows + @batch_rows;

-- print status message:

raiserror('Rows affected: %d', 0, 1, @total_rows) with nowait;

-- if no rows were deleted, then break from loop:

if @batch_rows = 0 break;

end;