Re: Partitioning Tables

I had a typo:

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

CREATE TABLE 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
thePARITION BY LIST does not support referencing a parent table.
 

Lance

On 2/5/21, 1:18 PM, "Campbell, Lance" <lance@illinois.edu> wrote:

    This is what I really want to do.  But it does not look like PostgreSQL supports referencing the parent tables for
decidingwhat 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
otherwisethe PARITION BY LIST does not support referencing a parent table.
 
    
    Lance 
    
    On 2/5/21, 12:42 PM, "Scott Ribe" <scott_ribe@elevated-dev.com> wrote:
    
        > On Feb 5, 2021, at 11:27 AM, Campbell, Lance <lance@illinois.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
andthe row will get redirected into the right place. Some older versions (I don't remember how old) required you to
insertinto 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
getsmoved. 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
befast, but you'd still wind up with the matching rows scattered all over the single big tablee