More on Volatile Tables

Volatile tables are useful for the following:

• Creating tables that the system accesses and modifies frequently

• For when you know you do not need the data for later use

• Automatically dropping the table at session end

Using volatile tables enables the Optimizer to do an index scan instead of a table scan.

The definition of a volatile table is stored in memory cache only for the duration of the

current session. Space usage is charged to the spool space of the login user. If your SPOOL

allocation is large enough, you can create up to 1000 volatile tables per session.

Note: Volatile tables do not survive a Teradata Database reset. Restart processing destroys

both the contents and the definition of a volatile table.

The following are not available for volatile tables:

• Referential integrity constraints

• Check constraints

• Permanent journaling

• Compressed column values

• DEFAULT clause

• TITLE clause

• Named indexes

• Privilege checking (because volatile tables are private to the session in which they are

created)

• Identity Column