The explain plan shows that all partitions will be scanned but i believe that plan isn't valid because the check constraint that dictates which partition to access can't be known until the query is executed due to the value being a join. You can see what i mean using the SQL below.
I have no "proof" that the partition isn't being used except for query execution timings. When I execute the same join query but i hardcode the check constraint value, the query executes significantly faster, essentially with the same timing as using a single partition table directly.
create table parent(n integer);
create table data_partitions.child1() inherits(parent);
alter table data_partitions.child1 add constraint ck1child check (n=1);
insert into data_partitions.child1 values(1);
create table data_partitions.child2() inherits(parent);
alter table data_partitions.child2 add constraint ck2child check (n=2);
insert into data_partitions.child2 values(2);
create table joiner(m integer, n integer);
insert into joiner values(0,1),(1,2);
-- These two obviously use the partitions.
explain select * from parent where n = 1;
explain select * from parent where n = 2;
-- This one doesn't use the partition (in the execution plan).
explain select * from parent join joiner on parent.n = joiner.n and joiner.m = 0;
-- This does use the proper partition.
explain select * from parent join joiner on parent.n = joiner.n and joiner.m = 0 and joiner.n=1;