I am working with PostgreSQL 14. I have a table called Order
with a status column:
CREATE TABLE "Order" (
"orderId" BIG SERIAL PRIMARY KEY NOT NULL,
"orderDescription" TEXT NOT NULL,
"statusId" SMALLINT NOT NULL
) PARTITION BY RANGE ("statusId");
As shown, this table is partitioned by RANGE
based on the statusId
. We need to place orders that have moved to a closed status in a separate partition. To achieve this, I implemented a simple trick. I defined a table called OrderStatus
and assigned open statuses in the range of 10
to 20
and closed statuses in the range of 20
to 30
:
CREATE TABLE "OrderStatus" (
"statusId" SMALLINT PRIMARY KEY NOT NULL,
"statusName" VARCHAR UNIQUE NOT NULL
);
INSERT INTO "OrderStatus" ("statusId", "statusName") VALUES (11, 'WAITING'); -- open
INSERT INTO "OrderStatus" ("statusId", "statusName") VALUES (12, 'OPEN'); -- open
INSERT INTO "OrderStatus" ("statusId", "statusName") VALUES (13, 'CANCELING'); -- open
INSERT INTO "OrderStatus" ("statusId", "statusName") VALUES (14, 'SENDING'); -- open
INSERT INTO "OrderStatus" ("statusId", "statusName") VALUES (21, 'FINISHED'); -- close
INSERT INTO "OrderStatus" ("statusId", "statusName") VALUES (22, 'CANCELED'); -- close
Based on this, the partitions are defined as follows:
CREATE TABLE "Order_Open" PARTITION OF "Order" FOR VALUES FROM (10) TO (20);
CREATE TABLE "Order_Close" PARTITION OF "Order" FOR VALUES FROM (20) TO (30);
So far, everything works as expected.
Now, we are undergoing a system refactor, and one of the proposed changes is to convert the order statuses to an enum type. However, if we do this, since the numeric values of enums (enumsortorder
column in pg_enum
table) are defined by PostgreSQL, it seems that the trick we used for categorizing open and closed statuses will no longer be applicable.
Here are the potential solutions I have considered, each with its own explanation, but I'm not sure if they are the best approaches:
Add a new boolean column
isOpen
to indicate whether the order is open or closed, and partition the table based on this column. I feel that having an additional column for this information is not ideal.Manipulate the
enumsortorder
values of the enum in thepg_enum
table to retain our categorization trick (I haven't tried this yet to see if it's possible). This approach seems risky and not quite right to me.Change the partitioning type to
LIST
. While this does not pose significant issues, if we need to add a new value to the enum in the future, we would have to change the table definitions, which is not appealing.Abandon the idea of using enum altogether and steel use
statusId
ofOrderStatus
table. I feel that for cases where we need to partition a table based on a column, using enum might not be suitable, especially forRANGE
partitioning.
Maybe there's a best practice for this situation that I'm not aware of. If anyone can provide insights or advice on this, I would greatly appreciate it.