I'd be concerned about the Logical Scan Fragmentation value... that is excessively high.
You also haven't specified how many indexes/triggers exist on that table - remember that for each row inserted it also has to insert into each index and execute each trigger which will slow down your overall insert process.
TRUNCATE TABLE TempTable
Insert into TempTable
left join TableA on
TableA_Stage.Field1 = TableA.Field1
where TableA.Field1 is null
Insert into TableA
(*) I rewrote your original INSERT statement, it seemed flawed to me.
With kind regards . . . . . SQL Server 2000/2005/2012
Grabel's Law: 2 is not equal to 3 -- not even for very large values of 2. Pat Phelan's Law: 2 very definitely CAN equal 3 -- in at least two programming languages
Looking through the information here: You have some kind of stage table, and a table that you want to update with information from the stage table. My first question: The column (or columns) that you join on, are they guaranteed to be unique? If so, you should consider having a unique index (on this/these column(s)) on both the stage and target table, it could speed up your join drastically. Otherwise, a non-unique index could do the same, but if possible a unique index would be preferred.
If this is some kind of incremental load, I would suggest adding a timestamp column to your stage table, and create a stored proc for the insert. This should log the Timestamp values read, and only read the rows with greater timestamp. This could very well be done in combination with indexes. I've just done something similar myself, and large updates went from 8 minutes to 3 seconds.
Are the indexes that are rebuilt every week used in this process? updating a table (or inserting/deleting) requires index maintenance. If there are 50 indexes on the table, the inserts would take a long time.