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
Adds the pgmq extension to support queuing (#1120)
* add pgmq SQL only extension
* revert accidental file inclusion
* add public interface test coverage
* order by namespace for tables in interface test to make timescale stable since they use 3 schemas
* pgmq in prime
* update to pgmq 1.4.2
* regression tests for pgmq
* add pgmq migration test script
* add pg_partman
* remove pg_partman_bgq from test suite postgresql.conf
* checkin broken test
* checkin broken test 2
* bump pgmq to 1.4.4
* sync test outputs and pg_partman with 1.4.4
* add pgmq to supautils privileged extensions
For native partitioning, you must start with a parent table that has already been set up to be partitioned in the desired type. Currently pg_partman only supports the RANGE type of partitioning (both for time & id). You cannot turn a non-partitioned table into the parent table of a partitioned set, which can make migration a challenge. This document will show you some techniques for how to manage this later. For now, we will start with a brand new table in this example. Any non-unique indexes can also be added to the parent table in PG11+ and they will automatically be created on all child tables.
6
+
*/
7
+
create table partman_test.time_taptest_table(
8
+
col1 int,
9
+
col2 text default 'stuff',
10
+
col3 timestamptz not null default now()
11
+
)
12
+
partition by range (col3);
13
+
create index on partman_test.time_tap (col3);
14
+
ERROR: relation "partman_test.time_tap" does not exist
15
+
/*
16
+
Unique indexes (including primary keys) cannot be created on a natively partitioned parent unless they include the partition key. For time-based partitioning that generally doesn't work out since that would limit only a single timestamp value in each child table. pg_partman helps to manage this by using a template table to manage properties that currently are not supported by native partitioning. Note that this does not solve the issue of the constraint not being enforced across the entire partition set. See the main documentation to see which properties are managed by the template.
17
+
18
+
Manually create the template table first so that when we run create_parent() the initial child tables that are created will have a primary key. If you do not supply a template table to pg_partman, it will create one for you in the schema that you installed the extension to. However properties you add to that template are only then applied to newly created child tables after that point. You will have to retroactively apply those properties manually to any child tables that already existed.
0 commit comments