Re: Partitioning Tables

This is what I really want to do. But it does not look like PostgreSQL supports referencing the parent tables for deciding what partition to put the data in:

CREATE TABLE group_manager.group (id INTEGER, type TEXT, name TEXT, CONSTRAINT group_pkey PRIMARY KEY (id) );
-- type would have values of A , B or C

CREATE TABLE group_member (fk_group_id INTEGER, id INTEGER, user_id TEXT) PARTITION BY LIST(group.type);

-- Above PARTITION BY LIST(group.type) does not work.

CREATE TABLE group_member_A PARTITION OF group_member FOR VALUES IN ('A');
CREATE TABLE group_member_B PARTITION OF group_member FOR VALUES IN ('B');
CREATE TABLE group_member_C PARTITION OF group_member FOR VALUES IN ('C');

It does look like it would work if I added the "type" from the group table to the group_member table. But otherwise the PARITION BY LIST does not support referencing a parent table.

Lance

On 2/5/21, 12:42 PM, "Scott Ribe" <scott_ribe(at)elevated-dev(dot)com> wrote:

> On Feb 5, 2021, at 11:27 AM, Campbell, Lance <lance(at)illinois(dot)edu> wrote:
>
> So if I do a query like the below it would ideally pull from partition group_member_a rather than group_member_other. However, how would PostgreSQL know on insert a group_member into the proper partition?
>
> Select group_member.* from group, group_member WHERE group.type=’A’ and group.id=group_member.user=’bob smith’;

When you define the partition, you declare what values go into it. With PG 12, you can insert into the parent and the row will get redirected into the right place. Some older versions (I don't remember how old) required you to insert into the right table, or some voodoo with rewrite rules or triggers.

In other words, smarts about which partitions to scan in your example pre-dates smarts about inserting.

I don't remember for sure, but I think maybe PG 13 adds the feature where if you update the group type, the row gets moved. Prior, you'd have to delete and re-insert. Someone correct me?

> Also, what happens if I did a query like this. Will it know to scan both group_member_a and group_member_other:
>
> Select group_member.* from group_member where group_member.user=’bob smith’;

Yes.

Anyway, you are on the right track, in that what you're describing could work.

There are less invasive things you could try, which wouldn't give as much benefit--like partial indexes

for instance

create index ... on group_member(user) where type = 'A'

that gets you fast location of a single user, but if you looked for a range of users, reading the index would be fast, but you'd still wind up with the matching rows scattered all over the single big tablee