To: dclements89@gmail.com
cc: pgsql-sql <pgsql-sql@postgresql.org>
Subject: Re: Fwd: Help required on query performance 
In-reply-to: <1f30b80c1001311650q264dfda0uf9894cac3b9e0c3e@mail.gmail.com> 
References: <1f30b80c1001290049ub864091r8298fca3daa0eb69@mail.gmail.com>
	<1f30b80c1001311650q264dfda0uf9894cac3b9e0c3e@mail.gmail.com>
Comments: In-reply-to Dave Clements <dclements89@gmail.com>
	message dated "Mon, 01 Feb 2010 11:50:22 +1100"
Date: Sun, 31 Jan 2010 22:32:20 -0500
Message-ID: <28233.1264995140@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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.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