Thursday, September 12, 2013

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

Identity Column

No comments:

Post a Comment