Autopartitioning v6.0.1

Autopartitioning in PGD allows you to split tables into several partitions, other tables, creating and dropping those partitions are needed. Autopartitioning is useful for managing large tables that grow over time as it allows you to separate the data into manageable chunks. For example, you can archive older data into its own partition, and then archive or drop the partition when the data is no longer needed.

Autopartitioning and replication

PGD autopartitioning is managed, by default, locally through the bdr.autopartition function. This function allows you to create or alter the definition of automatic range partitioning for a table. If no definition exists, it creates one; otherwise, it alters the existing definition.

Range partitioning

PGD autopartitioning supports range partitioning using the RANGE keyword. Range partitioning allows you to partition a table based on the ranges of values in a column. For example, you can partition a table by date, where each partition contains data for a specific date range. This is useful for managing large tables that grow over time, as it allows you to separate the data into manageable chunks.

For example, you can create a table that is partitioned by date:

CREATE TABLE measurement (
    logdate date not null,
    peaktemp int,
    unitsales int
) PARTITION BY RANGE (logdate);

Then, you can use the bdr.autopartition function to create daily partitions and keep data for one month:

select bdr.autopartition('measurement', '1 day', data_retention_period := '30 days');

This function creates a partition for each day and retains the data for 30 days. After 30 days, the partitions are automatically dropped. If you look at the database tables you'll see the partitions created for the measurement table:

pgddb=# \dt

                               List of relations
 Schema |                  Name                  |       Type        |  Owner
--------+----------------------------------------+-------------------+----------
 public | measurement                            | partitioned table | postgres
 public | measurement_part_1231354915_2103027132 | table             | postgres
 public | measurement_part_1520219330_1231354915 | table             | postgres
 public | measurement_part_1670975046_3921991865 | table             | postgres
 public | measurement_part_2103027132_2095358725 | table             | postgres
 public | measurement_part_2877346473_1670975046 | table             | postgres
 public | measurement_part_3921991865_1520219330 | table             | postgres
(7 rows)

Why are there so many partitions? Because, by default, the autopartition creates five advance partitions, for future use and will automatically do that whenever it uses all but two of the partitions. This means that it will always have at least two partitions available for new data. You can change this behavior by setting the minimum_advance_partitions and maximum_advance_partitions parameters in the bdr.autopartition function.

bdr.autopartition(relation regclass,
		partition_increment text,
		partition_initial_lowerbound text DEFAULT NULL,
		partition_autocreate_expression text DEFAULT NULL,
		minimum_advance_partitions integer DEFAULT 2,
		maximum_advance_partitions integer DEFAULT 5,
		data_retention_period interval DEFAULT NULL,
		enabled boolean DEFAULT on,
		analytics_offload_period);