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
• Identity Column