Article View: borland.public.interbase.sql
Article #636Re: optimizing query ..
From: Karol Bieniaszewski
Date: Mon, 17 Sep 2007 09:51
Date: Mon, 17 Sep 2007 09:51
78 lines
3222 bytes
3222 bytes
U�ytkownik "Wayne Niddery [TeamB]" <wniddery@chaffaci.on.ca> napisa� w wiadomo�ci news:46ea9edd$1@newsgroups.borland.com... > Karol Bieniaszewski wrote: >> >> FROM >> TABLE_B B >> INNER JOIN TABLE_A A ON B.ID_OBJ=A.ID >> INNER JOIN TABLE_C C ON C.ID_OBJ=A.ID AND B.SYSTEM=C.SYSTEM AND >> C.ZRODLO=:PARAM_X >> WHERE >> B.KOD=PARAM_Y >> AND B.SYSTEM=PARAM_Z > > Don't know if it will change anything, but "C.ZRODLO=:PARAM_X" should be > in the Where clause, not in the join condition. > >> FROM >> TABLE_B B >> INNER JOIN TABLE_A A ON B.ID_OBJ=A.ID >> INNER JOIN (TABLE_C C LEFT JOIN TABLE_D D ON C.ALARM=D.NAZWA) ON >> C.ID_OBJ=A.ID AND B.SYSTEM=C.SYSTEM AND C.ZRODLO=:PARAM_X >> WHERE >> B.KOD=PARAM_Y >> AND B.SYSTEM=PARAM_Z > > I have never seen any advantage in nesting joins, breaking them out as you > do below is more readable, and, IME, has no negative effect on > performance. > >> FROM >> TABLE_B B >> INNER JOIN TABLE_A A ON B.ID_OBJ=A.ID >> INNER JOIN TABLE_C C ON C.ID_OBJ=A.ID AND B.SYSTEM=C.SYSTEM AND >> C.ZRODLO=:PARAM_X >> LEFT JOIN TABLE_D D ON C.ALARM=D.NAZWA >> WHERE >> B.KOD=PARAM_Y >> AND B.SYSTEM=PARAM_Z >> >> but without success >> now A is NATURAL > > A natural scan on A is more easily understandable here because you clearly > have no conditions on table A, thus it makes more sense to simply scan it > and perform indexed lookups in the other tables. What performance are you > getting with this version compared to any of the others? > > I would try this: > > FROM > TABLE_C C > INNER JOIN TABLE_A A ON A.ID=C.ID_OBJ > INNER JOIN TABLE_B B ON B.ID_OBJ=C.ID_OBJ AND B.SYSTEM=C.SYSTEM > LEFT JOIN TABLE_D D ON D.NAZWA=C.ALARM > WHERE > C.ZRODLO=:PARAM_X > AND B.KOD=:PARAM_Y > AND B.SYSTEM=:PARAM_Z > > How does that change the plan and performance? > > -- now plan is :( PLAN JOIN (JOIN (A NATURAL,C INDEX (IXA_TABLE_C__OBJ__ZRO__SYS),B INDEX (IXA_TABLE_B__KOD__SYSTEM, FK_TABLE_B__ID_OBJ)),D INDEX (IXAU__TABLE_D__NAZWA)) i write best (at this time) plan manually PLAN JOIN (B INDEX (IXA_TABLE_B__KOD__SYSTEM), A INDEX (PK_TABLE_A__ID), C INDEX (IXA_TABLE_C__OBJ__ZRO__SYS)) but this query (where clause) can by modified by user by type in search form thanks for help Karol Bieniaszewski
Technical Details
Message-ID:
<46ee4c91$1@newsgroups.borland.com>Path:
arc1-ca.pugleaf.net!g2news2.google.com!news1.google.com!news2.google.com!news.glorb.com!newsfeeds.ihug.co.nz!ihug.co.nz!newsgroups.borland.com!not-for-mailReferences:
<46ea51f5$1@newsgroups.borland.com> <46ea9edd$1@newsgroups.borland.com>Show Full Headers
Complete Article Headers
X-Google-Thread: 114a0e,27cb88e47143e0c2 X-Google-Attributes: gid114a0e,public,usenet X-Google-Language: ENGLISH,ASCII From: "Karol Bieniaszewski" <liviuslivius@poczta.onet.pl> Newsgroups: borland.public.interbase.sql References: <46ea51f5$1@newsgroups.borland.com> <46ea9edd$1@newsgroups.borland.com> Subject: Re: optimizing query .. Date: Mon, 17 Sep 2007 11:51:21 +0200 Lines: 80 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-RFC2646: Format=Flowed; Response NNTP-Posting-Host: 195.205.151.58 Message-ID: <46ee4c91$1@newsgroups.borland.com> X-Trace: newsgroups.borland.com 1190022289 195.205.151.58 (17 Sep 2007 02:44:49 -0700) Path: arc1-ca.pugleaf.net!g2news2.google.com!news1.google.com!news2.google.com!news.glorb.com!newsfeeds.ihug.co.nz!ihug.co.nz!newsgroups.borland.com!not-for-mail