Article View: borland.public.interbase.sql
Article #560Re: Performance with nested SELECT
From: Svein Erling Tysvær
Date: Sat, 22 Sep 2007 21:26
Date: Sat, 22 Sep 2007 21:26
78 lines
3952 bytes
3952 bytes
Hi Tiedo!
I cannot tell why your query takes that much longer, but in general I
think using COUNT in a subquery can be slow and I've never even tried
using a GROUP BY within a subquery. I think your example can be written
a bit differently:
SELECT DISTINCT G.GerechtigdeID, G.AdminNrPensioen
FROM G_Gerecht G
JOIN T_SelectStanden T ON G.GerechtigdeID = T.GerechtigdeID
JOIN G_RekenBasis B ON B.GerechtigdeID = G.GerechtigdeID
WHERE B.RekenBasisCode = 50
AND EXISTS(SELECT *
FROM G_Gerecht Gr
JOIN T_SelectStanden Tr ON Gr.GerechtigdeID = Tr.GerechtigdeID
JOIN G_RekenBasis Br ON Br.GerechtigdeID = Gr.GerechtigdeID
WHERE Br.RekenBasisCode = 50
AND B.RekenBasisID = Br.RekenBasisID
AND NOT EXISTS(SELECT *
FROM G_RekenBasis Br2
WHERE Br2.GerechtigdeID = Gr.GerechtigdeID
AND Br2.RekenBasisCode = 50
AND Br.RekenBasisID < Br2.RekenBasisID))
ORDER BY G.AdminNrPensioen
I'm a bit too tired just now to check whether this is right or if it can
be simplified, but HTH,
Set
Tiedo Kruisselbrink wrote:
> I am using IB 2007
>
> In my small testdatabase this query:
> SELECT DISTINCT G.GerechtigdeID, G.AdminNrPensioen
> FROM G_Gerecht G
> JOIN T_SelectStanden T ON G.GerechtigdeID = T.GerechtigdeID
> JOIN G_RekenBasis B ON B.GerechtigdeID = G.GerechtigdeID
> WHERE B.RekenBasisCode = 50
> takes 0.05 sec to fetch 6 rows
>
> this query:
> SELECT MAX(Br.RekenBasisID)
> FROM G_Gerecht Gr
> JOIN T_SelectStanden Tr ON Gr.GerechtigdeID = Tr.GerechtigdeID
> JOIN G_RekenBasis Br ON Br.GerechtigdeID = Gr.GerechtigdeID
> WHERE Br.RekenBasisCode = 50
> GROUP BY Br.RekenbasisCode, Br.GerechtigdeID
> takes 0.02 sec to fetch 6 rows
> (in this simple testcase this are the same 6 rows)
>
> Now I use the second query nested in the first:
> SELECT DISTINCT G.GerechtigdeID, G.AdminNrPensioen
> FROM G_Gerecht G
> JOIN T_SelectStanden T ON G.GerechtigdeID = T.GerechtigdeID
> JOIN G_RekenBasis B ON B.GerechtigdeID = G.GerechtigdeID
> WHERE B.RekenBasisCode = 50
> AND B.RekenBasisID IN
> (
> SELECT MAX(Br.RekenBasisID)
> FROM G_Gerecht Gr
> JOIN T_SelectStanden Tr ON Gr.GerechtigdeID = Tr.GerechtigdeID
> JOIN G_RekenBasis Br ON Br.GerechtigdeID = Gr.GerechtigdeID
> WHERE Br.RekenBasisCode = 50
> GROUP BY Br.RekenbasisCode, Br.GerechtigdeID
> )
> ORDER BY G.AdminNrPensioen
> This time it takes 4.39 sec. to fetch the same 6 records.
>
> Since both queries can be executed independent, I expected 0.05 + 0.02
> = 0.07 sec.
> Even when IB executes the inner query again for each row of the outer
> query, I would expect only 0.05 + (6 * 0.02) = 0.17 sec.
> Why does it take this extreme long? What can I do about it?
>
> (when I try this in SQL Server, everything is going as fast as I
> expected)
>
> Thanks, Tiedo
Technical Details
Message-ID:
<46f58874@newsgroups.borland.com>Path:
arc1-ca.pugleaf.net!g2news2.google.com!news2.google.com!news.glorb.com!newsfeeds.ihug.co.nz!ihug.co.nz!newsgroups.borland.com!not-for-mailReferences:
<46f3ca37@newsgroups.borland.com>Show Full Headers
Complete Article Headers
X-Google-Thread: 114a0e,944d700dd0a5b55a X-Google-Attributes: gid114a0e,public,usenet X-Google-Language: DUTCH,ASCII-7-bit Date: Sat, 22 Sep 2007 23:26:19 +0200 From: Svein Erling Tysvær <svein.erling.tysvaer@kreftregisteret.no> User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 Newsgroups: borland.public.interbase.sql Subject: Re: Performance with nested SELECT References: <46f3ca37@newsgroups.borland.com> In-Reply-To: <46f3ca37@newsgroups.borland.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-6, 22.09.2007), Outbound message X-Antivirus-Status: Clean NNTP-Posting-Host: 80.202.75.228 Message-ID: <46f58874@newsgroups.borland.com> X-Trace: newsgroups.borland.com 1190496372 80.202.75.228 (22 Sep 2007 14:26:12 -0700) Lines: 78 Path: arc1-ca.pugleaf.net!g2news2.google.com!news2.google.com!news.glorb.com!newsfeeds.ihug.co.nz!ihug.co.nz!newsgroups.borland.com!not-for-mail