Pallav Kalva <pkalva@xxxxxxxxxxxxxxxxx> writes:
> I have analyzed tables again and also my default_stats_target is set to
> 100, still it shows the same plan.
>>> -> Index Scan using idx_accountactivity_fkactivityid on
>>> accountactivity accountact0_ (cost=0.00..3.94 rows=1 width=16)
>>> Index Cond: (accountact0_.fkactivityid =
>>> activity1_.activityid)
>>> Filter: (fkaccountid = 1455437)
>>> -> Index Scan using
>>> idx_accountactivity_fkaccountid on accountactivity accountact0_
>>> (cost=0.00..1641.42 rows=1343 width=16) (actual time=115.348..864.416
>>> rows=10302 loops=1)
>>> Index Cond: (fkaccountid = 1455437)
Oh, my bad, I failed to look closely enough at these subplans.
I thought they were identical but they're not using the same scan
conditions, so the rowcount estimates shouldn't be comparable after all.
Could you try EXPLAINing (maybe even with ANALYZE) the query *without*
the LIMIT clause? I'm curious to see what it thinks the best plan is
then.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
