On 21 Jan 2005 at 8:38, Russell Smith wrote:

> On Fri, 21 Jan 2005 02:36 am, Dan Langille wrote:
> > On 20 Jan 2005 at 7:26, Stephan Szabo wrote:
> [snip]
> > > Honestly I expected it to be slower (which it was), but I figured
> > > it's worth seeing what alternate plans it'll generate
> > > (specifically to see how it cost a nested loop on that join to
> > > compare to the fast plan). Unfortunately, it generated a merge
> > > join, so I think it might require both enable_hashjoin=false and
> > > enable_mergejoin=false to get it which is likely to be even slower
> > > in practice but still may be useful to see.
> > 
> > Setting both to false gives a dramatic performance boost.  See
> > http://rafb.net/paste/results/b70KAi42.html
> > 
>          ->  Materialize  (cost=15288.70..15316.36 rows=2766 width=35)
>          (actual time=0.004..0.596 rows=135 loops=92)
>                ->  Nested Loop  (cost=0.00..15288.70 rows=2766
>                width=35) (actual time=0.060..9.130 rows=135 loops=1)
> The Planner here has a quite inaccurate guess at the number of rows
> that will match in the join.  An alternative to turning off join types
> is to up the statistics on the Element columns because that's where
> the join is happening.  Hopefully the planner will get a better idea. 
> However it may not be able too.  2766 rows vs 135 is quite likely to
> choose different plans.  As you can see you have had to turn off two
> join types to give something you wanted/expected.

Fair comment.  However, the statistics on ports.element_id, 
ports.deprecated, ports.broken, and element.id are both set to 1000.

> > This gives suitable speed, but why does the plan vary so much with
> > such a minor change in the WHERE clause?
> Plan 1 - broken
>        ->  Nested Loop  (cost=0.00..3825.30 rows=495 width=35) (actual
>        time=0.056..16.161 rows=218 loops=1)
> Plan 2 - deprecated
>         ->  Hash Join  (cost=3676.78..10144.06 rows=2767 width=35)
>         (actual time=7.638..1158.128 rows=135 loops=1)
> The performance difference is when the where is changed, you have a
> totally different set of selection options. The Plan 1 and Plan 2
> shown from your paste earlier, report that you are out by a factor of
> 2 for plan 1.  But for plan 2 its a factor of 20.  The planner is
> likely to make the wrong choice when the stats are out by that factor.
> Beware what is a small "typing" change does not mean they queries are
> anything alight.

Agreed.  I just did not expect such a dramatic change which a result 
set that is similar.  Actually, they aren't that similar at all.

Thank you.
Dan Langille : http://www.langille.org/
BSDCan - The Technical BSD Conference - http://www.bsdcan.org/

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to