Rod Taylor <rbt@rbt.ca> writes:
>> -> Hash Join (cost=3D1230.79..60581.82 rows=3D158 width=3D54)=
> (actual time=3D1262.35..151200.29 rows=3D1121988 loops=3D1)
>> Hash Cond: ("outer".account_id =3D "inner".account_id)
>> -> Hash Join (cost=3D1226.78..52863.43 rows=3D1542558 w=
> idth=3D50) (actual time=3D1261.63..100418.30 rows=3D1573190 loops=3D1)
>> (join of bsod, tsb, tss)
(btw, would you mind turning off MIME encoding in your mails to the PG
lists? It's a real PITA to quote.)
> So yes, since this is a full table scan all values will be joined since
> the foreign key enforces them all to exist.
Well, no, because only 1121988 rows come out of the join when 1573190
went in. So the actual selectivity of the join is about 70%. The
question is why the planner is estimating the selectivity at 0.01%
(158/1542558).
Could we see the pg_stats rows for service.account_id and
account.account_id?
regards, tom lane