Dave Clements <dclement...@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.95 rows=8 width=153) (actual
time=0.781..310.579 rows=975 loops=1)
...
-> Bitmap Heap Scan 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
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
