Dave Clements <dclements89@gmail.com> writes:
> Hello, I have this query in my system which takes around 2.5 seconds
> to run. I have diagnosed that the problem is actually a hashjoin on
> perm and s_ast_role tables. Is there a way I can avoid that join?
BTW, just for the record, that diagnosis was completely off. The
upper level of your explain results is
HashAggregate (cost=38145.19..38145.20 rows=1 width=149) (actual time=2635.965..2636.086 rows=243 loops=1) -> Nested
Loop (cost=15.00..38145.18 rows=1 width=149) (actual time=4.417..2635.086 rows=598 loops=1) -> Nested Loop
(cost=4.13..37993.95rows=8 width=153) (actual time=0.781..310.579 rows=975 loops=1) ... -> Bitmap
HeapScan on sq_ast_lnk_tree t (cost=10.87..18.88 rows=2 width=4) (actual time=2.382..2.382 rows=1 loops=975)
...
from which we can see that the main problem is doing the sq_ast_lnk_tree
scan over again 975 times, once per row coming out of the other side of
the join. That accounted for 975*2.382 = 2322.450 msec, or the vast
majority of the runtime. The planner wouldn't have picked this plan
except that it thought that only 8 rows would come out of the other side
of the join; repeating the scan 8 times seemed better than the
alternatives. After you improved the statistics, it most likely
switched *to* a hash join (or possibly a merge join) for this step,
rather than switching away from one.
regards, tom lane