Partitioning samples also for HASH and LIST

Author: kmoppel

07_table_partitioning.sql renamed to 07_1_table_partitioning_range.sql

@@ -6,7 +6,8 @@ SET ROLE TO demorole;
 When it can be already foreseen that a table will grow huge (100+ GB) or there is for example a "hot data" / "cold data"
 scenario, then it makes sense to think about splitting up the table to so called partitions. And the good thing is that
 starting from v10 there is native support for that - so that users can continue to work with the "main" or "top level"
-table and not care or know about the sub-partitions where data rows are actually living in.
+table and not care or know about the sub-partitions where data rows are actually living in. Note though that pre-creation
+of such sub-partitions needs to be managed by the user - but also some extensions can help with that, like 'pg_partman'.
 
 Different partitioning models available:
 

07_2_table_partitioning_hash.sql

@@ -0,0 +1,41 @@
+\c pg_features_demo
+SET ROLE TO demorole;
+
+/*
+
+HASH partitioning, available from v11, differentiates quite a lot from LIST and RANGE methods and in short takes care of
+even distribution of data for us - we just say how many sub-partitions we need (need to pre-create these as with other
+partitioning types) and which column will be used for calculating the hash which then will be used to choose the partition
+where some row will land.
+
+Hash partitioning is especially suited for "key-value" or "NoSQL" use cases and it helps to increase query throughput a
+lot as user CRUD will be more parallel / contention free and also many background Autovacuum processes can work on the
+table simultaneously. Also you can use Postgres safeguarded real primary keys with hashing without problems which is problematic
+with other partitioning types.
+
+*/
+
+-- the "main" or "parent" table that users will be interacting with
+CREATE TABLE web_sessions (
+    session_id        uuid NOT NULL PRIMARY KEY,
+    -- data columns ...
+    created_on        timestamptz NOT NULL DEFAULT now(),
+    last_modified_on  timestamptz,
+    session_data      jsonb
+
+) PARTITION BY HASH (session_id);
+
+-- partition to hold data for year 2019
+CREATE TABLE web_sessions_0 PARTITION OF web_sessions FOR VALUES WITH (MODULUS 4, REMAINDER 0);
+CREATE TABLE web_sessions_1 PARTITION OF web_sessions FOR VALUES WITH (MODULUS 4, REMAINDER 1);
+CREATE TABLE web_sessions_2 PARTITION OF web_sessions FOR VALUES WITH (MODULUS 4, REMAINDER 2);
+CREATE TABLE web_sessions_3 PARTITION OF web_sessions FOR VALUES WITH (MODULUS 4, REMAINDER 3);
+
+-- we keep working with the "main" table ...
+INSERT INTO web_sessions(session_id, session_data)
+    SELECT 'a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11', '{"auth_token": "eeshu8tiiChe4AeP4junaiyie7thewu5"}';
+
+SELECT * FROM web_sessions; -- 1 row
+
+-- if you want to disable implicit scanning of sub-tables one can use the ONLY keyword
+SELECT * FROM ONLY web_sessions; -- 0 rows

07_3_table_partitioning_list.sql

@@ -0,0 +1,28 @@
+\c pg_features_demo
+SET ROLE TO demorole;
+
+/*
+
+LIST partitioning is probably the least used partitioning method but it gives you very explicit control over where data
+for some particular data sets should be stored. This can be for example used to implement some fine controlled "multi-tenant"
+behaviour, where some big / active customers for example have their own "table" or maybe also to implement some "hot-cold data"
+scenarios where orders, once processed are shifted to a separate partition for faster summary analytics. Note though that
+automatic moving of rows between partitions on partitioning key updates are available only from v11.
+
+*/
+
+-- the "main" or "parent" table that users will be interacting with
+CREATE TABLE orders_segmented (
+    client_id       int8 NOT NULL,
+    order_nr        int8 NOT NULL,
+    order_date      timestamptz NOT NULL DEFAULT now(),
+    -- data columns ...
+    UNIQUE (client_id, order_nr)
+) PARTITION BY LIST (client_id);
+
+-- data for major customer 1
+CREATE TABLE orders_client_1 PARTITION OF orders_segmented FOR VALUES IN (1);
+-- data for major customer 2
+CREATE TABLE orders_client_2 PARTITION OF orders_segmented FOR VALUES IN (2);
+-- 1 shared partition for all the smaller "fish"
+CREATE TABLE orders_client_def PARTITION OF orders_segmented DEFAULT;