Re: [HACKERS] advanced partition matching algorithm forpartition-wise join - Mailing list pgsql-hackers
From | Etsuro Fujita |
---|---|
Subject | Re: [HACKERS] advanced partition matching algorithm forpartition-wise join |
Date | |
Msg-id | CAPmGK15ZpZ_CTDhAuLjFRAZNA0k0jM2WEej8jOQhabq_ZCVx4Q@mail.gmail.com Whole thread Raw |
In response to | Re: [HACKERS] advanced partition matching algorithm forpartition-wise join (Etsuro Fujita <etsuro.fujita@gmail.com>) |
Responses |
Re: [HACKERS] advanced partition matching algorithm forpartition-wise join
|
List | pgsql-hackers |
On Fri, Feb 7, 2020 at 9:57 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote: > On Thu, Feb 6, 2020 at 3:55 AM Mark Dilger <mark.dilger@enterprisedb.com> wrote: > > The patches apply and pass all tests. A review of the patch vs. master looks reasonable. I've merged the patches. Attached is a new version of the patch. > > The partition_join.sql test has multiple levels of partitioning, but when your patch extends that test with “advancedpartition-wise join”, none of the tables for the new section have multiple levels. I spent a little while reviewingthe code and inventing multiple level partitioning tests for advanced partition-wise join and did not encounterany problems. I don’t care whether you use this particular example, but do you want to have multiple level partitioningin the new test section? > > Yes, I do. > > > CREATE TABLE alpha (a double precision, b double precision) PARTITION BY RANGE (a); > > CREATE TABLE alpha_neg PARTITION OF alpha FOR VALUES FROM ('-Infinity') TO (0) PARTITION BY RANGE (b); > > CREATE TABLE alpha_pos PARTITION OF alpha FOR VALUES FROM (0) TO ('Infinity') PARTITION BY RANGE (b); > > CREATE TABLE alpha_nan PARTITION OF alpha FOR VALUES FROM ('Infinity') TO ('NaN'); > > CREATE TABLE alpha_neg_neg PARTITION OF alpha_neg FOR VALUES FROM ('-Infinity') TO (0); > > CREATE TABLE alpha_neg_pos PARTITION OF alpha_neg FOR VALUES FROM (0) TO ('Infinity'); > > CREATE TABLE alpha_neg_nan PARTITION OF alpha_neg FOR VALUES FROM ('Infinity') TO ('NaN'); > > CREATE TABLE alpha_pos_neg PARTITION OF alpha_pos FOR VALUES FROM ('-Infinity') TO (0); > > CREATE TABLE alpha_pos_pos PARTITION OF alpha_pos FOR VALUES FROM (0) TO ('Infinity'); > > CREATE TABLE alpha_pos_nan PARTITION OF alpha_pos FOR VALUES FROM ('Infinity') TO ('NaN'); > > INSERT INTO alpha (a, b) > > (SELECT * FROM > > (VALUES (-1.0::float8), (0.0::float8), (1.0::float8), ('Infinity'::float8)) a, > > (VALUES (-1.0::float8), (0.0::float8), (1.0::float8), ('Infinity'::float8)) b > > ); > > ANALYZE alpha; > > ANALYZE alpha_neg; > > ANALYZE alpha_pos; > > ANALYZE alpha_nan; > > ANALYZE alpha_neg_neg; > > ANALYZE alpha_neg_pos; > > ANALYZE alpha_neg_nan; > > ANALYZE alpha_pos_neg; > > ANALYZE alpha_pos_pos; > > ANALYZE alpha_pos_nan; > > CREATE TABLE beta (a double precision, b double precision) PARTITION BY RANGE (a, b); > > CREATE TABLE beta_lo PARTITION OF beta FOR VALUES FROM (-5, -5) TO (0, 0); > > CREATE TABLE beta_me PARTITION OF beta FOR VALUES FROM (0, 0) TO (0, 5); > > CREATE TABLE beta_hi PARTITION OF beta FOR VALUES FROM (0, 5) TO (5, 5); > > INSERT INTO beta (a, b) > > (SELECT * FROM > > (VALUES (-1.0::float8), (0.0::float8), (1.0::float8)) a, > > (VALUES (-1.0::float8), (0.0::float8), (1.0::float8)) b > > ); > > ANALYZE beta; > > ANALYZE beta_lo; > > ANALYZE beta_me; > > ANALYZE beta_hi; > > EXPLAIN SELECT * FROM alpha INNER JOIN beta ON (alpha.a = beta.a AND alpha.b = beta.b) WHERE alpha.a = 1 AND beta.b =1; > > QUERY PLAN > > ------------------------------------------------------------------------------- > > Nested Loop (cost=0.00..2.11 rows=1 width=32) > > -> Seq Scan on alpha_pos_pos alpha (cost=0.00..1.06 rows=1 width=16) > > Filter: ((b = '1'::double precision) AND (a = '1'::double precision)) > > -> Seq Scan on beta_hi beta (cost=0.00..1.04 rows=1 width=16) > > Filter: ((b = '1'::double precision) AND (a = '1'::double precision)) > > (5 rows) > > Hmm, I'm not sure this is a good test case for that, because this > result would be due to partition pruning applied to each side of the > join before considering partition-wise join; you could get the same > result even with enable_partitionwise_join=off. I think it's > important that the partition-wise join logic doesn't break this query, > though. I think this would be beyond the scope of the patch, so I added different test cases that I think would be better as ones for multi-level partitioning. Thanks! Best regards, Etsuro Fujita
Attachment
pgsql-hackers by date: