pinfo is a parent table with two partitions pinfo_p00 and pinfo_p01, all three have primary keys on pid and partitions have proper constraints that guarantee pid uniqueness across them.
Now here's the part of the query:
select * from contacts c left join pinfo pi on (pi.pid = c.cpid)
QUERY PLAN -> Nested Loop Left Join (cost=0.00..444.90 rows=1515 width=408) (actual time=0.108..5.561 rows=44 loops=1) Join Filter: (pi.pid = c.cpid) -> Index Scan using ix_contacts_pid on contacts c (cost=0.00..14.84 rows=50 width=26) (actual time=0.038..0.425 rows=44 loops=1) Index Cond: (pid = 167) -> Append (cost=0.00..8.56 rows=3 width=386) (actual time=0.067..0.090 rows=1 loops=44) -> Index Scan using pk_pinfo on pinfo pi (cost=0.00..1.15 rows=1 width=386) (actual time=0.008..0.008 rows=0 loops=44) Index Cond: (pi.pid = c.cpid) -> Index Scan using pk_pinfo_p00 on pinfo_p00 pi (cost=0.00..3.23 rows=1 width=46) (actual time=0.011..0.014 rows=0 loops=44) Index Cond: (pi.pid = c.cpid) -> Index Scan using pk_pinfo_p01 on pinfo_p01 pi (cost=0.00..4.19 rows=1 width=46) (actual time=0.011..0.014 rows=0 loops=44) Index Cond: (pi.pid = c.cpid)
How come that outermost join expects 1515 rows given the row estimations of the inner and outer nested loop's parts?