In 7X, partitions are first-class tables. There is no such thing as alias (partition name) in 7X, therefore pg_partitons.partitionname
and pg_partitons.parentpartitionname
no longer make sense and not available either.
Take the following table partrl
as an example:
Below is the pg_partitions
entry in 6X for leaf partition partrl_1_prt_p2_2_prt_sp1
.
partitionname = 'sp1'
and parentpartitionname = 'p2'
are not applicable in 7X. In 7X, we'd only have partitionschemaname = 'partrl_1_prt_p2'
and parentpartitiontablename = 'partrl_1_prt_p2_2_prt_sp1'
.
partitionname
and parentpartitionname
in the first place?It looks like parentpartitionname
has been used to identify subpartitions. In 7X, there are multiple ways to acquire such information:
pg_class.relispartition = 't' and pg_class.relkind = 'p'
to identify a middle-level table. pg_partition_ancestors()
.This design philosophy difference affects the usage of the pg_partition_columns
view.
The entires of the pg_partition_columns
view in 6X for the example partrl
table looks like below:
However, in 7X, middle level partitions on the same level may be partitioned w/ differernt strategies AND partition keys. So, in 7X, using a given root table and a level can not uniquely identify the partition strategy and key(s). It seems this view is mostly used to fetch column name of specified partition level.
Example heterogeneous partition hierachy in 7X:
In 7X, had we have the pg_partition_columns
view available, the entries for partrlr
would look like below:
This view seems unnecessary/misleading in 7X because:
pg_partitioned_table
and pg_attribute
.FOR RANK
is not valid syntax in 7XInstead use FOR VALUE
in ALTER TABLE ALTER PARTITION
clause to refer to a child partition. Because of the removal of the FOR RANK
syntax, pg_partitions.partitionrank
is not required by many user queries, hence neither calculated nor stored in the catalog.
For range partition maintenance purposes, such as finding the highest or lowest partition boundries, we may still want to sort partitions by their partition boundaries, for those cases, we can evaluate the usage and create UDFs based on 7X catalog.
pg_dump
and pg_restore
use modern syntaxKeeping pg_partitions.partitionboundary
which stores partition boundary specification in classic syntax may be unnecessary and even error prone.
pg_partitions.partitionposition
is not stored in the catalogFor range partitions, partitionposition
is same as partitionrank
, they are not stored in the catalog. We can acquire them by writing custom queries or UDFs to sort the range partition boundaries.
List partition has problem with it.
For list partitions, partitionposition
monotonically increases as new list partitions being created. This information we don't store in 7X's catalog, and we can't reconstruct either.
For hash partitions, which is new in Greenplum, we don't have a definition for partitionposition
with hash partitions.
pg_partitions.partitionstartinclusive
: always truepg_partitions.partitionendinclusive
: always falsepg_partitions.partitioneveryclause
: always NULLpg_class.relpartbound
stores partition boundaries in 7XExample in 7X:
from which partitionrangestart
, partitionrangeend
, partitionlistvalues
can be parsed, if needed.
pg_partitions.partitionlevel
is one offTaking partrl
as an example:
In 7X, root partition is at level 0 and leaf partitions are at level 2:
In 6X, pg_partitions
doesn't have an entry for root table partrl
, and partitionlevel
starts from 0 for root table's direct children and 1 for the leaf partitions:
So pg_partitions.partitionlevel
and level
returned from pg_partition_tree()
is one off, which is not a problem, but can be confusing.
schema of this view is problematic for
Unavailable fields:
Dummy fields:
Potential irrelavent field:
Potential misleading field:
pg_class.relpartbound
for partition maintenance:partitionrank
partitionrangestart
partitionrangeend
partitionisdefault
pg_class.relpartbound
has them:partitionlistvalues
partitionisdefault
Need to look more into pg_partman.
Easy to get, naming convention may not be consistant w/ new catalog:
schemaname
: root table's schema name
tablename
: root table's table name
partitionschemaname
: this partition's schema name
partitionname
: this partitions table name
parentpartitiontablename
: parent table's schema name is parent is not root
parentpartitionname
: parent table's table name if parent is not root
partitiontype
: parent's partition by strategy
partitionlevel
: parent's partition level
partitionposition
:
partitionlistvalues
: parse text from list partition's relpartbound
partitionrangestart
: parse text from range partition's relpartbound
partrangestartinclusive
: if not null always true
partitionrangeend
: parse text from range partition's relpartbound
partitionrangeinclusive
: if not null always false
partitionisdefault
: parse from relpartbound
parenttablespce
:
partitiontablespace
:
Missing in new catalog tables but can write UDF:
partitionrank
: for range partition only, starting from 1. index of this partition after ordering the range partition boundaries
partitionposition
: same as partitionrank
for range partitions, monotonically increasing number for list partitions
Need to understand usage:
partitionboundary
: convert pg_get_expr(relpartbound) to classic syntax
schemaname
: root table's schema name
tablename
: root table's table name
columnname
: partition key
partitionlevel
: start from 0
position_in_partition_key
: always 0 for range partition and can be greater than 0 for list partition.