LAB 5: Partitioning (2)

Patitioning by hash
Certainly! Below is an example of hash partitioning the orders table from the TPC-H schema
using the HASH partitioning method in PostgreSQL:
-- Create the main orders table
CREATE TABLE orders (
orderkey INTEGER PRIMARY KEY,
orderdate DATE,
shippriority INTEGER,
totalprice DECIMAL(15, 2),
-- Other columns...
);

-- Create hash partitions

CREATE TABLE orders_partition_1 PARTITION OF orders
FOR VALUES WITH (MODULUS 4, REMAINDER 0);

CREATE TABLE orders_partition_2 PARTITION OF orders

FOR VALUES WITH (MODULUS 4, REMAINDER 1);

CREATE TABLE orders_partition_3 PARTITION OF orders

FOR VALUES WITH (MODULUS 4, REMAINDER 2);

CREATE TABLE orders_partition_4 PARTITION OF orders

FOR VALUES WITH (MODULUS 4, REMAINDER 3);

In this example, the orders table is hash partitioned into four partitions based on the modulo and
remainder. You can adjust the number of partitions and the modulus/remainder values based on your
specific needs.
Hash partitioning is useful when you want to distribute data evenly across partitions, and it can help
balance the workload among different partitions.
Keep in mind that the effectiveness of hash partitioning depends on the distribution of your data and
the nature of your queries. In some cases, it might be more suitable than range partitioning,
especially if you don't have clear range boundaries.
Make sure to choose appropriate data types, adjust the number of partitions, and consider the
characteristics of your dataset for an optimal partitioning strategy.
Partitioning by Range
Certainly! Below is an example of partitioning the orders table from the TPC-H schema using the
RANGE partitioning method in PostgreSQL:
-- Create the main orders table
CREATE TABLE orders (
orderkey INTEGER PRIMARY KEY,
orderdate DATE,
shippriority INTEGER,
totalprice DECIMAL(15, 2),
-- Other columns...
);

-- Create partitions based on the orderdate range

CREATE TABLE orders_1992_q1
PARTITION OF orders
FOR VALUES FROM ('1992-01-01') TO ('1992-04-01');

CREATE TABLE orders_1992_q2

PARTITION OF orders
FOR VALUES FROM ('1992-04-01') TO ('1992-07-01');

CREATE TABLE orders_1992_q3

PARTITION OF orders
FOR VALUES FROM ('1992-07-01') TO ('1992-10-01');

CREATE TABLE orders_1992_q4

PARTITION OF orders
FOR VALUES FROM ('1992-10-01') TO ('1993-01-01');

In this example, the orders table is partitioned based on the orderdate column, and each
partition represents a quarter of the year. You can create additional partitions for subsequent years or
adjust the partition ranges based on your specific needs.
Note that in PostgreSQL, the PARTITION OF syntax is used to create partitions, and you specify
the range for each partition using the FOR VALUES FROM clause.

This is a simplified example, and in a real-world scenario, you would need to consider the specific
requirements of your workload, the distribution of data, and the nature of your queries to determine
the most effective partitioning strategy. Additionally, you should choose appropriate data types and
adjust the partition ranges based on the actual characteristics of your data.
Multi-column range patitioning
The TPC-H benchmark is a standard decision support benchmark that involves a set of business
queries. To illustrate three-column partitioning with a simple example, let's consider a subset of the
TPC-H schema involving three columns: orderdate, shippriority, and totalprice.

Here's an example of how you might create a partitioned table for a simplified version of the Orders
table from TPC-H:
CREATE TABLE orders (
orderkey INTEGER,
orderdate DATE,
shippriority INTEGER,
totalprice DECIMAL(15, 2),
-- Other columns...
) PARTITION BY RANGE (orderdate, shippriority, totalprice);

CREATE TABLE orders_low VALUES FROM (MINVALUE, MINVALUE, MINVALUE) TO ('1995-01-

01', 3, 5000);
CREATE TABLE orders_medium VALUES FROM ('1995-01-01', 3, 5000) TO ('1996-01-01',
5, 10000);
CREATE TABLE orders_high VALUES FROM ('1996-01-01', 5, 10000) TO (MAXVALUE,
MAXVALUE, MAXVALUE);

In this example, the orders table is partitioned based on three columns: orderdate,
shippriority, and totalprice. Three partitions (orders_low, orders_medium, and
orders_high) are created with specified ranges for each of the columns.

Adjust the data types, column names, and partition ranges according to your specific needs and the
actual schema of your TPC-H dataset.
Remember to ensure that your version of PostgreSQL supports table partitioning (PostgreSQL 10
and later) and that partitioning is an appropriate optimization for your specific use case. It's also
worth noting that while partitioning can improve query performance in certain scenarios, it may not
be the best solution for every use case, and its effectiveness depends on factors such as the nature of
your queries and the distribution of your data.
Multi-column list patitioning
In a real-world scenario, the decision to use list partitioning would depend on the nature of the data
and the specific requirements of your queries. Here is a simplified example of how you might
perform list partitioning for a simplified orders table from the TPC-H schema based on three
columns: orderdate, shippriority, and totalprice.
-- Create the main orders table
CREATE TABLE orders (
orderkey INTEGER PRIMARY KEY,
orderdate DATE,
shippriority INTEGER,
totalprice DECIMAL(15, 2),
-- Other columns...
);

-- Create list partitions based on the values of orderdate, shippriority, and

totalprice
CREATE TABLE orders_low_priority PARTITION OF orders
FOR VALUES IN ('1992-01-01', 1, 5000);

CREATE TABLE orders_medium_priority PARTITION OF orders

FOR VALUES IN ('1992-01-01', 2, 10000);

CREATE TABLE orders_high_priority PARTITION OF orders

FOR VALUES IN ('1992-01-01', 3, 15000);

-- Create a catch-all partition for values not covered by the specific lists
CREATE TABLE orders_default_partition PARTITION OF orders
FOR VALUES IN (DEFAULT);

In this example, orders table is partitioned based on the specific values of orderdate,
shippriority, and totalprice. Three list partitions (orders_low_priority,
orders_medium_priority, and orders_high_priority) are created, each
corresponding to a specific combination of values. The orders_default_partition is a
catch-all partition for values that do not match any of the specific lists.
Please note that in practice, you would need to carefully consider the distribution of your data and
the specific requirements of your queries to determine the most effective partitioning strategy.
Additionally, keep in mind that while partitioning can improve performance in some scenarios, it
may not be the best solution for every use case
Patition by reference
PostgreSQL supports reference partitioning starting from version 11. Reference partitioning allows
you to create a partitioned table where each partition corresponds to a different value in a referenced
table. Let's create a simplified example using the customer and orders tables from the TPC-H
schema:
-- Create the main customer table
CREATE TABLE customer (
custkey INTEGER PRIMARY KEY,
name VARCHAR(50),
nationkey INTEGER,
-- Other columns...
);

-- Create the main orders table

CREATE TABLE orders (
orderkey INTEGER PRIMARY KEY,
custkey INTEGER REFERENCES customer(custkey),
orderdate DATE,
shippriority INTEGER,
totalprice DECIMAL(15, 2),
-- Other columns...
);

-- Create reference partitions based on the nationkey column in the customer

table
CREATE TABLE orders_usa PARTITION OF orders
FOR VALUES FROM (1) TO (2)
PARTITION BY REFERENCE customer(custkey);

CREATE TABLE orders_canada PARTITION OF orders

FOR VALUES FROM (3) TO (3)
PARTITION BY REFERENCE customer(custkey);

CREATE TABLE orders_other PARTITION OF orders

FOR VALUES FROM (4) TO (MAXVALUE)
PARTITION BY REFERENCE customer(custkey);

In this example, the orders table is partitioned based on the nationkey column in the
referenced customer table. Three partitions (orders_usa, orders_canada, and
orders_other) are created based on the values of nationkey in the customer table.

Reference partitioning can be particularly useful when there is a natural relationship between the
data in the main table and the partitioning key in the referenced table. This can simplify data
management and improve query performance for certain types of queries.
Make sure to adjust the column names, data types, and partition ranges based on your specific needs
and the actual schema of your TPC-H dataset.