Creating partitioned tables in PostgreSQL - Practice Exercises

Challenge - 5 Problems

❓ query_result

intermediate

Output of inserting data into a range partitioned table

Consider the following PostgreSQL partitioned table setup:

CREATE TABLE sales (
  id SERIAL PRIMARY KEY,
  sale_date DATE NOT NULL,
  amount NUMERIC
) PARTITION BY RANGE (sale_date);

CREATE TABLE sales_2023 PARTITION OF sales
  FOR VALUES FROM ('2023-01-01') TO ('2024-01-01');

CREATE TABLE sales_2024 PARTITION OF sales
  FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');

INSERT INTO sales (sale_date, amount) VALUES
  ('2023-06-15', 100),
  ('2024-03-10', 200);

SELECT tableoid::regclass, sale_date, amount FROM sales ORDER BY sale_date;

What will be the output of the SELECT query?

PostgreSQL

CREATE TABLE sales (
  id SERIAL PRIMARY KEY,
  sale_date DATE NOT NULL,
  amount NUMERIC
) PARTITION BY RANGE (sale_date);

CREATE TABLE sales_2023 PARTITION OF sales
  FOR VALUES FROM ('2023-01-01') TO ('2024-01-01');

CREATE TABLE sales_2024 PARTITION OF sales
  FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');

INSERT INTO sales (sale_date, amount) VALUES
  ('2023-06-15', 100),
  ('2024-03-10', 200);

SELECT tableoid::regclass, sale_date, amount FROM sales ORDER BY sale_date;

A

sales_2023 | 2024-03-10 | 200
sales_2024 | 2023-06-15 | 100

B

sales_2023 | 2023-06-15 | 100
sales_2024 | 2024-03-10 | 200

C

sales | 2023-06-15 | 100
sales | 2024-03-10 | 200

D Error: no partition for value

💡 Hint

Remember that data inserted into a partitioned table is stored in the matching partition table.

The data is routed to the correct partition based on the sale_date. The first row goes to sales_2023 because its date is in 2023, the second to sales_2024. The tableoid::regclass shows the actual partition table name.

🧠 Conceptual

intermediate

Choosing partition key type for performance

You want to create a partitioned table in PostgreSQL to store user logs. The logs have a timestamp column and a user_id column. You expect queries mostly filter by date ranges and sometimes by user_id.

Which partitioning strategy is best for optimizing query performance?

A Partition by RANGE on the timestamp column

B Partition by LIST on the user_id column

C Partition by HASH on the user_id column

D Partition by RANGE on the user_id column

💡 Hint

Think about which column is most commonly used in WHERE clauses and how partition pruning works.

Since queries mostly filter by date ranges, partitioning by RANGE on the timestamp column allows PostgreSQL to skip irrelevant partitions efficiently. Partitioning by user_id would not help range queries on dates.

📝 Syntax

advanced

Identify the syntax error in partition creation

Which of the following CREATE TABLE statements for a partitioned table is syntactically correct in PostgreSQL?

A

CREATE TABLE orders (
  id INT,
  order_date DATE
) PARTITION BY RANGE (order_date);

B

CREATE TABLE orders (
  id INT,
  order_date DATE
) PARTITION BY LIST (order_date);

C

CREATE TABLE orders (
  id INT,
  order_date DATE
) PARTITIONED BY RANGE (order_date);

D

CREATE TABLE orders (
  id INT,
  order_date DATE
) PARTITION BY RANGE order_date;

💡 Hint

Check the exact syntax for partitioning in PostgreSQL.

Option A is correct as it uses PARTITION BY RANGE (order_date). Option A is correct syntax for LIST partitioning. Option A uses invalid keyword PARTITIONED BY. Option A misses parentheses after RANGE.

🔧 Debug

advanced

Why does this insert fail on a partitioned table?

Given this partitioned table setup:

CREATE TABLE events (
  id SERIAL PRIMARY KEY,
  event_type TEXT NOT NULL
) PARTITION BY LIST (event_type);

CREATE TABLE events_login PARTITION OF events FOR VALUES IN ('login');
CREATE TABLE events_logout PARTITION OF events FOR VALUES IN ('logout');

INSERT INTO events (event_type) VALUES ('signup');

Why does the INSERT statement fail?

A The partition tables are missing primary keys

B The event_type column cannot be NULL

C No partition exists for the value 'signup' in event_type

D The PARTITION BY LIST syntax is invalid

💡 Hint

Think about how PostgreSQL routes data to partitions.

Since there is no partition defined for the value 'signup' in the event_type column, PostgreSQL cannot find a matching partition and raises an error.

❓ optimization

expert

Optimizing query performance on a large partitioned table

You have a large PostgreSQL table partitioned by RANGE on a date column with monthly partitions. You notice queries filtering on date ranges are slow.

Which of the following actions will most likely improve query performance?

A Drop all indexes and rely on sequential scans

B Create a global index on the parent partitioned table

C Convert the partitioning to LIST on the date column

D Create indexes on the partition key column in each partition

💡 Hint

Consider how indexes work with partitioned tables in PostgreSQL.

PostgreSQL does not support global indexes on partitioned tables. Indexes must be created on each partition individually to speed up queries filtering on the partition key.

Practice

1. What is the main purpose of creating partitioned tables in PostgreSQL?

easy

A. To split a large table into smaller, manageable parts based on a column

B. To create multiple copies of the same table for backup

C. To combine several tables into one large table

D. To encrypt the data in a table for security

Solution

1. Step 1: Understand partitioning concept

   Partitioned tables divide a big table into smaller parts based on a column value, improving management and query performance.

2. Step 2: Compare options

   Backup, merging several tables, and encryption are not related to partitioning.

3. Final Answer:

   To split a large table into smaller, manageable parts based on a column -> Option A

4. Quick Check:

   Partitioned tables split big tables = A [OK]

Hint: Partitioning means splitting big tables by column values [OK]

Common Mistakes:

• Confusing partitioning with backup or encryption
• Thinking partitioning merges tables instead of splitting
• Assuming partitioning duplicates data

2. Which of the following is the correct syntax to create a partitioned table by range on column created_date?

easy

A. CREATE TABLE orders PARTITION BY LIST (created_date);

B. CREATE TABLE orders PARTITION ON RANGE (created_date);

C. CREATE TABLE orders PARTITION BY HASH (created_date);

D. CREATE TABLE orders PARTITION BY RANGE (created_date);

Solution

1. Step 1: Recall partition syntax

   PostgreSQL uses PARTITION BY RANGE (column) to create range partitions.

2. Step 2: Check options

   CREATE TABLE orders PARTITION BY RANGE (created_date); uses correct syntax. CREATE TABLE orders PARTITION ON RANGE (created_date); uses wrong keyword 'PARTITION ON'. PARTITION BY LIST and PARTITION BY HASH use different partition types.

3. Final Answer:

   CREATE TABLE orders PARTITION BY RANGE (created_date); -> Option D

4. Quick Check:

   Correct syntax uses PARTITION BY RANGE [OK]

Hint: Use PARTITION BY RANGE (column) for range partitions [OK]

Common Mistakes:

• Using PARTITION ON instead of PARTITION BY
• Mixing partition types (LIST or HASH) when RANGE is needed
• Omitting parentheses around column name

3. Given the following commands, what will be the result of querying SELECT * FROM sales WHERE sale_year = 2023;?

CREATE TABLE sales (
  id INT,
  sale_year INT,
  amount NUMERIC
) PARTITION BY LIST (sale_year);

CREATE TABLE sales_2022 PARTITION OF sales FOR VALUES IN (2022);
CREATE TABLE sales_2023 PARTITION OF sales FOR VALUES IN (2023);

INSERT INTO sales VALUES (1, 2022, 100), (2, 2023, 200), (3, 2023, 300);

medium

A. Rows with id 2 and 3 will be returned

B. Rows with id 1 and 2 will be returned

C. Only row with id 1 will be returned

D. No rows will be returned

Solution

1. Step 1: Understand partitioning by LIST on sale_year

   Table sales is partitioned by sale_year with partitions for 2022 and 2023.

2. Step 2: Analyze inserted data and query

   Rows with sale_year 2023 have ids 2 and 3. Query filters sale_year = 2023, so these rows are returned.

3. Final Answer:

   Rows with id 2 and 3 will be returned -> Option A

4. Quick Check:

   Query filters sale_year=2023, returns matching rows [OK]

Hint: Query returns rows matching partition values [OK]

Common Mistakes:

• Assuming all rows return regardless of partition
• Confusing partition column with other columns
• Forgetting to insert data into partitions

4. Identify the error in the following partition creation commands:

CREATE TABLE logs (
  id SERIAL,
  log_date DATE
) PARTITION BY RANGE (log_date);

CREATE TABLE logs_2023 PARTITION OF logs FOR VALUES FROM ('2023-01-01') TO ('2024-01-01');

medium

A. Partitioning by RANGE is not allowed on DATE columns

B. Missing PRIMARY KEY on the parent table

C. The TO value should be '2024-01-01' to include all 2023 dates

D. FOR VALUES clause should use LIST instead of RANGE

Solution

1. Step 1: Check RANGE partition boundaries

   RANGE partitions include values from FROM (inclusive) up to TO (exclusive). To cover all 2023 dates, TO must be '2024-01-01'.

2. Step 2: Analyze given TO value

   TO is '2023-12-31', which excludes that date and any after. This causes missing data for 2023-12-31.

3. Final Answer:

   The TO value should be '2024-01-01' to include all 2023 dates -> Option C

4. Quick Check:

   RANGE TO is exclusive, so use next day [OK]

Hint: RANGE TO value is exclusive; use next day after range end [OK]

Common Mistakes:

• Using inclusive TO value in RANGE partitions
• Thinking RANGE partitioning disallows DATE columns
• Confusing LIST and RANGE partition syntax

5. You want to create a partitioned table events partitioned by HASH on user_id with 4 partitions. Which set of commands correctly creates the table and its partitions?

hard

A. CREATE TABLE events (id INT, user_id INT) PARTITION BY HASH (user_id);
CREATE TABLE events_p0 PARTITION OF events FOR VALUES IN (0);
CREATE TABLE events_p1 PARTITION OF events FOR VALUES IN (1);
CREATE TABLE events_p2 PARTITION OF events FOR VALUES IN (2);
CREATE TABLE events_p3 PARTITION OF events FOR VALUES IN (3);

B. CREATE TABLE events (id INT, user_id INT) PARTITION BY HASH (user_id);
CREATE TABLE events_p0 PARTITION OF events FOR VALUES WITH (MODULUS 4, REMAINDER 0);
CREATE TABLE events_p1 PARTITION OF events FOR VALUES WITH (MODULUS 4, REMAINDER 1);
CREATE TABLE events_p2 PARTITION OF events FOR VALUES WITH (MODULUS 4, REMAINDER 2);
CREATE TABLE events_p3 PARTITION OF events FOR VALUES WITH (MODULUS 4, REMAINDER 3);

C. CREATE TABLE events (id INT, user_id INT) PARTITION BY LIST (user_id);
CREATE TABLE events_p0 PARTITION OF events FOR VALUES IN (0);
CREATE TABLE events_p1 PARTITION OF events FOR VALUES IN (1);
CREATE TABLE events_p2 PARTITION OF events FOR VALUES IN (2);
CREATE TABLE events_p3 PARTITION OF events FOR VALUES IN (3);

D. CREATE TABLE events (id INT, user_id INT) PARTITION BY RANGE (user_id);
CREATE TABLE events_p0 PARTITION OF events FOR VALUES FROM (0) TO (1);
CREATE TABLE events_p1 PARTITION OF events FOR VALUES FROM (1) TO (2);
CREATE TABLE events_p2 PARTITION OF events FOR VALUES FROM (2) TO (3);
CREATE TABLE events_p3 PARTITION OF events FOR VALUES FROM (3) TO (4);

Solution

1. Step 1: Understand HASH partition syntax

   HASH partitions require FOR VALUES WITH (MODULUS n, REMAINDER r) to define partitions.

2. Step 2: Check each option

   CREATE TABLE events (id INT, user_id INT) PARTITION BY HASH (user_id); CREATE TABLE events_p0 PARTITION OF events FOR VALUES WITH (MODULUS 4, REMAINDER 0); CREATE TABLE events_p1 PARTITION OF events FOR VALUES WITH (MODULUS 4, REMAINDER 1); CREATE TABLE events_p2 PARTITION OF events FOR VALUES WITH (MODULUS 4, REMAINDER 2); CREATE TABLE events_p3 PARTITION OF events FOR VALUES WITH (MODULUS 4, REMAINDER 3); correctly uses HASH partitioning with modulus 4 and remainders 0 to 3. CREATE TABLE events (id INT, user_id INT) PARTITION BY HASH (user_id); CREATE TABLE events_p0 PARTITION OF events FOR VALUES IN (0); CREATE TABLE events_p1 PARTITION OF events FOR VALUES IN (1); CREATE TABLE events_p2 PARTITION OF events FOR VALUES IN (2); CREATE TABLE events_p3 PARTITION OF events FOR VALUES IN (3); uses LIST syntax incorrectly. CREATE TABLE events (id INT, user_id INT) PARTITION BY LIST (user_id); CREATE TABLE events_p0 PARTITION OF events FOR VALUES IN (0); CREATE TABLE events_p1 PARTITION OF events FOR VALUES IN (1); CREATE TABLE events_p2 PARTITION OF events FOR VALUES IN (2); CREATE TABLE events_p3 PARTITION OF events FOR VALUES IN (3); uses LIST partitioning, not HASH. CREATE TABLE events (id INT, user_id INT) PARTITION BY RANGE (user_id); CREATE TABLE events_p0 PARTITION OF events FOR VALUES FROM (0) TO (1); CREATE TABLE events_p1 PARTITION OF events FOR VALUES FROM (1) TO (2); CREATE TABLE events_p2 PARTITION OF events FOR VALUES FROM (2) TO (3); CREATE TABLE events_p3 PARTITION OF events FOR VALUES FROM (3) TO (4); uses RANGE partitioning, not HASH.

3. Final Answer:

   The commands using PARTITION BY HASH (user_id) with FOR VALUES WITH (MODULUS 4, REMAINDER 0-3) -> Option B

4. Quick Check:

   HASH partitions use MODULUS and REMAINDER [OK]

Hint: HASH partitions use MODULUS and REMAINDER in FOR VALUES WITH clause [OK]

Common Mistakes:

• Using FOR VALUES IN instead of FOR VALUES WITH for HASH
• Mixing partition types (LIST or RANGE) with HASH
• Omitting modulus or remainder values