Temp tables and deferred updates

Question

Does anyone know why the following update to #test and #test1 is deferred, but the same update to the permanent table inputtable is direct?
I haven't found any documentation that would explain this.
@@version is Adaptive Server Enterprise/15.7.0/EBF 22305 SMP SP61 /P/Sun_svr4/OS 5.10/ase157sp6x/3341/64-bit/FBO/Fri Feb 21 11:55:38 2014
create proc proctest
as
begin
    -- inputtable.fiId is int not null
    -- Why this is a deferred update?
    select fiId into #test from inputtable
    update #test set fiId = 0
    -- Why this is a deferred update?
    create table #test1(fiId int not null)
    insert #test1 select fiId from inputtable
    update #test1 set fiId = 0
    -- Yay. This is a direct update.
    update inputtable set fiId = 0
end
go
set showplan on
go
exec proctest
go
       |ROOT:EMIT Operator (VA = 2)
       |
       |   |UPDATE Operator (VA = 1)
       |   |  The update mode is deferred.
       |   |
       |   |   |SCAN Operator (VA = 0)
       |   |   |  FROM TABLE
       |   |   |  #test
       |   |   |  Table Scan.
       |   |   |  Forward Scan.
       |   |   |  Positioning at start of table.
       |   |   |  Using I/O Size 16 Kbytes for data pages.
       |   |   |  With LRU Buffer Replacement Strategy for data pages.
       |   |
       |   |  TO TABLE
       |   |  #test
       |   |  Using I/O Size 2 Kbytes for data pages.
       |ROOT:EMIT Operator (VA = 2)
       |
       |   |UPDATE Operator (VA = 1)
       |   |  The update mode is deferred.
       |   |
       |   |   |SCAN Operator (VA = 0)
       |   |   |  FROM TABLE
       |   |   |  #test1
       |   |   |  Table Scan.
       |   |   |  Forward Scan.
       |   |   |  Positioning at start of table.
       |   |   |  Using I/O Size 16 Kbytes for data pages.
       |   |   |  With LRU Buffer Replacement Strategy for data pages.
       |   |
       |   |  TO TABLE
       |   |  #test1
       |   |  Using I/O Size 2 Kbytes for data pages.
       |ROOT:EMIT Operator (VA = 2)
       |
       |   |UPDATE Operator (VA = 1)
       |   |  The update mode is direct.
       |   |
       |   |   |SCAN Operator (VA = 0)
       |   |   |  FROM TABLE
       |   |   |  inputtable
       |   |   |  Table Scan.
       |   |   |  Forward Scan.
       |   |   |  Positioning at start of table.
       |   |   |  Using I/O Size 16 Kbytes for data pages.
       |   |   |  With LRU Buffer Replacement Strategy for data pages.
       |   |
       |   |  TO TABLE
       |   |  inputtable
       |   |  Using I/O Size 2 Kbytes for data pages.

Answer 1

I don't have a documentation reference but the optimizer appears to default to deferred mode when the #table and follow-on DML operation are in the same batch (ie, optimizer makes a 'safe' guess during optimization based on limited details of #table schema).
You can get the queries to operate in direct mode by forcing the optimizer to (re)compile the UPDATEs after the #tables have been created, eg:
- create #table outside of proc; during proc creation/execution the #tables already exist so optimizer can choose direct mode
- perform UPDATEs within exec() construct; exec() calls are processed within a separate/subordinate context, ie, #table is know at time exec() call is compiled so direct mode can be chosen; obvious downside is the overhead for the exec() call and associated compilation phase ... which may be an improvement over a) executing UPDATE in deferred mode and/or b) recompiling the proc (see next bullet), ymmv
- induce a schema change to the #table so proc is recompiled (with #table details known during the recompile) thus allowing use of direct mode; while adding/dropping indexes/constraints/columns will suffice these also add extra processing overhead; I'd suggest a fairly benign schema change that also has little/no effect on table (eg, alter table #test replace fiId default null); obvious downside to this approach is the forced recompilation of the stored proc, which could add considerably to proc run times depending on volume/complexity of queries in the rest of the proc