You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+9-1Lines changed: 9 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,10 +4,18 @@
4
4
NEW FEATURES
5
5
------------
6
6
- Add support for microsecond precisions in epoch partitioning. (Github PR #659)
7
-
- Improve partition maintenance performance when determining next partition to created. (Github Issue #660)
7
+
- Improve partition maintenance performance when determining next partition to be created. (Github Issue #660)
8
8
- Removed requirement for pg_partman to be installed as a superuser. See "superuser" parameter in control file documentation for more details - https://www.postgresql.org/docs/current/extend-extensions.html#EXTEND-EXTENSIONS-FILES
9
9
- Do not create partitions during a maintenance run that aren't going to be kept as part of retention anyway. (Github Issue #649)
10
+
- Removed `default_table` column from `part_config` table. It's only necessary in `part_config_sub` to determine whether future sub-partition parents should have defaults made. Adjusted other code to look up whether a default table actually exists to determine its behavior. (Github Issue #637)
11
+
- Allow the control column to be NULL. This is not advised without very careful review and an explicit use-case defined as it can cause unexpected behavior or excessive data in the DEFAULT child partition. A new flag `p_control_not_null` has been added to the `create_parent()` and `create_sub_parent()` functions.
10
12
13
+
BUG FIXES
14
+
---------
15
+
- Enforcement of the control column being NOT NULL was not being done as intended. This has been fixed. If you'd like to allow the control column to be NULL, see the new feature flag in 5.2.0
16
+
- Fixed `reapply_constraint_proc()` to work properly when there are no relevant child tables to place additional constraints. In the process reworked the logic to determine the target child tables for both that procedure and the apply_constraints() function. The determining factor is now always the newest child table that contains data (other than the default). Updated documentation to clarify how the optimize_constraint flag works. (Github Issue #694)
17
+
- Properly handle partial indexes that are inherited from the template table. (Github Issue #657)
18
+
- Move the retention logic for dropping tables later in the maintenance process to help avoid longer running heavy locks on partition sets. (Github Issue #678)
Copy file name to clipboardExpand all lines: doc/pg_partman.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -787,7 +787,7 @@ Stores all configuration data for partition sets managed by the extension.
787
787
-`constraint_cols`
788
788
- Array column that lists columns to have additional constraints applied. See **About** section for more information on how this feature works.
789
789
-`optimize_constraint`
790
-
- Manages which old tables get additional constraints set if configured to do so. See **About** section for more info. Default 30.
790
+
- Manages which old tables get additional constraints set if configured to do so. This value is a count on the number of child tables backwards from the newest child table that contains data. The default value of 30 means that the constraints will be created on the the child table that is 30 behind the newest child table that contains data. See **About** section for more info.
791
791
-`infinite_time_partitions`
792
792
- By default, new partitions in a time-based set will not be created if new data is not inserted to keep an infinite amount of empty tables from being created.
793
793
- If you'd still like new partitions to be made despite there being no new data, set this to TRUE.
@@ -114,20 +117,29 @@ IF p_child_table IS NULL THEN
114
117
v_step_id := add_step(v_job_id, 'Applying additional constraints: Automatically determining most recent child on which to apply constraints');
115
118
END IF;
116
119
117
-
SELECT partition_tablename INTO v_last_partition FROM @[email protected]_partitions(v_parent_table, 'DESC') LIMIT1;
120
+
-- Loop through child tables starting from highest to get a value from the highest non-empty partition in the set
121
+
-- Once a child table with a value is found, go back <optimize_constraint> children to make the constraint on that child
122
+
FOR v_row_max_value IN
123
+
SELECT partition_schemaname, partition_tablename FROM @[email protected]_partitions(p_parent_table, 'DESC', false)
124
+
LOOP
125
+
IF v_child_value IS NULL THEN
126
+
EXECUTE format('SELECT %L::text FROM %I.%I LIMIT 1'
127
+
, v_control
128
+
, v_row_max_value.partition_schemaname
129
+
, v_row_max_value.partition_tablename
130
+
) INTO v_child_value;
118
131
119
-
IF v_control_type ='time'OR (v_control_type ='id'AND v_epoch <>'none') THEN
120
-
SELECT child_start_time INTO v_last_partition_timestamp FROM @[email protected]_partition_info(v_parent_schema||'.'||v_last_partition, v_partition_interval, v_parent_table);
SELECT child_start_id INTO v_last_partition_id FROM @[email protected]_partition_info(v_parent_schema||'.'||v_last_partition, v_partition_interval, v_parent_table);
0 commit comments