Creating tables (permanent, temporary, transient) in Snowflake - Performance & Efficiency
Start learning this pattern below
Jump into concepts and practice - no test required
When creating tables in Snowflake, it is important to understand how the time taken grows as you create more tables.
We want to know how the number of operations changes when creating many tables.
Analyze the time complexity of the following operation sequence.
-- Create a permanent table
CREATE TABLE my_permanent_table (id INT, name STRING);
-- Create a temporary table
CREATE TEMPORARY TABLE my_temp_table (id INT, name STRING);
-- Create a transient table
CREATE TRANSIENT TABLE my_transient_table (id INT, name STRING);
-- Repeat creation for multiple tables
DECLARE i INT DEFAULT 1;
WHILE i <= 100 DO
EXECUTE IMMEDIATE 'CREATE TABLE table_' || i || ' (id INT, value STRING)';
LET i = i + 1;
END WHILE;
This sequence creates different types of tables and then creates many tables in a loop.
Identify the API calls, resource provisioning, data transfers that repeat.
- Primary operation: The CREATE TABLE command executed once per table.
- How many times: Once for each table created, for example 100 times in the loop.
Each new table requires a separate CREATE TABLE operation, so the total work grows as you create more tables.
| Input Size (n) | Approx. Api Calls/Operations |
|---|---|
| 10 | 10 CREATE TABLE commands |
| 100 | 100 CREATE TABLE commands |
| 1000 | 1000 CREATE TABLE commands |
Pattern observation: The number of operations grows directly with the number of tables created.
Time Complexity: O(n)
This means the time to create tables grows in a straight line as you create more tables.
[X] Wrong: "Creating multiple tables happens all at once, so time stays the same no matter how many tables."
[OK] Correct: Each CREATE TABLE is a separate operation that takes time, so more tables mean more total time.
Understanding how operations scale helps you design efficient database setups and shows you can think about system behavior as it grows.
"What if we created tables in parallel instead of one after another? How would the time complexity change?"
Practice
Solution
Step 1: Understand table types in Snowflake
Permanent tables store data permanently and include fail-safe for recovery.Step 2: Compare with other table types
Temporary tables last only for the session, and transient tables do not have fail-safe, so they are not recoverable after deletion.Final Answer:
PERMANENT table -> Option BQuick Check:
Permanent = long-term, recoverable [OK]
- Confusing transient with permanent tables
- Thinking temporary tables persist beyond session
- Assuming transient tables have fail-safe
session_data with columns id INT and value STRING in Snowflake?Solution
Step 1: Recall Snowflake syntax for temporary tables
The correct keyword is TEMPORARY placed right after CREATE and before TABLE.Step 2: Check each option's syntax
CREATE TEMPORARY TABLE session_data (id INT, value STRING); uses correct order and keywords. Options A, B, and C use incorrect or unsupported syntax.Final Answer:
CREATE TEMPORARY TABLE session_data (id INT, value STRING); -> Option CQuick Check:
CREATE TEMPORARY TABLE = correct syntax [OK]
- Using TEMP instead of TEMPORARY
- Placing TEMPORARY after table name
- Omitting TABLE keyword
CREATE TRANSIENT TABLE temp_cost (item STRING, price NUMBER);
INSERT INTO temp_cost VALUES ('apple', 1.2);
SELECT * FROM temp_cost;Solution
Step 1: Understand transient table behavior
Transient tables behave like permanent tables but without fail-safe. They accept inserts and can be queried normally.Step 2: Analyze the commands
The table is created, a row is inserted, and then selected. No errors or empty results expected.Final Answer:
[{'item': 'apple', 'price': 1.2}] -> Option DQuick Check:
Transient tables store and return inserted data [OK]
- Thinking transient tables cannot store data
- Expecting syntax error with TRANSIENT keyword
- Assuming transient tables auto-delete data immediately
CREATE TEMPORARY TABLE temp_users (user_id INT, name STRING);
Later, you try to query
temp_users in a new session but get an error. What is the most likely cause?Solution
Step 1: Recall temporary table lifecycle
Temporary tables exist only for the duration of the session that created them.Step 2: Understand session behavior
Querying in a new session fails because the temporary table no longer exists.Final Answer:
Temporary tables only exist during the session they were created in -> Option AQuick Check:
Temporary = session-only lifespan [OK]
- Assuming temp tables persist across sessions
- Confusing transient with temporary tables
- Ignoring session scope of temporary tables
Solution
Step 1: Identify table types and fail-safe behavior
Transient tables do not have fail-safe, reducing storage costs but keep data beyond session.Step 2: Match requirement with table type
Temporary tables are session-only, permanent tables have fail-safe, external tables are for external data.Final Answer:
CREATE TRANSIENT TABLE cost_savings (id INT, amount NUMBER); -> Option AQuick Check:
Transient = no fail-safe, cost-saving [OK]
- Choosing temporary tables which expire after session
- Using permanent tables with fail-safe enabled
- Confusing external tables with transient
