Subject | FB 1.5.2 takes longer than IB 6.0.2 to run simple SQL Statement |
---|---|
Author | hi_feroz |
Post date | 2005-01-26T06:18:52Z |
Hi,
Following SQL takes 4 sec in IB 6.0.2 and more than 30 sec in FB
1.5.2 and somtimes, FB even hangs when I run this. It takes 100% CPU
and hangs.
SELECT
R.CRS_CODE, R.MATRIC_NO, R.CRS_SECTION,
R.STU_CRS_STATUS_CODE,
R.CRS_NAME, R.CRS_CR_HRS,
O.CRS_CODE, O.VNU_CODE, O.VNU_CODE_2,
O.VNU_CODE_3,O.SLOT_DESC, O.SLOT_DESC_2, O.SLOT_DESC_3,
S.STU_NAME, S.STU_PRG_CODE,
CR.TOTAL_CR_HRS
FROM CRSREGCRE R, CRSOFFERCRE O, STUMST S, CREDIT_HRS_REG
('2004200501') CR
WHERE R.MATRIC_NO = S.MATRIC_NO
AND R.CRS_CODE = O.CRS_CODE
AND R.CRS_SECTION = O.CRS_SECTION
AND R.STR_CODE = O.STR_CODE
AND R.MATRIC_NO = CR.MATRIC_NO
AND R.STR_CODE = '2004200501'
ORDER BY R.MATRIC_NO, R.CRS_CODE
All the Fields in where clause are indexed except CRS_SECTION. It
doesnt make any difference.. I tried.
The procedure that I call in SQL is simple:
CREATE PROCEDURE CREDIT_HRS_REG (
I_STR_CODE VarChar(10))
returns (
MATRIC_NO VarChar(15),
TOTAL_CR_HRS Integer)
AS
BEGIN
FOR
SELECT MATRIC_NO, SUM(CRS_CR_HRS) AS TOTAL_CR_HRS
FROM CRSREGCRE
WHERE STR_CODE = :I_STR_CODE
AND STU_CRS_STATUS_CODE = 'R'
GROUP BY MATRIC_NO
INTO :MATRIC_NO,
:TOTAL_CR_HRS
Do
Begin
SUSPEND;
End
END
What could be the problem? Even if I take the procedure out and its
respective fields from the query.... FB still takes much longet than
IB. I tried many other procedures and queries, FB in most cases runs
much faster than IB. I am a little lost, why in this case it takes
longer?
OS = Windows XP
Processor = P4 2GHz
RAM = 256MB
FB and IB installed on same machine. But I run only one at a time
manually to do the test.
Originally DB was created in IB. I did the backup and restore when
using FB but still using the .GDB extension.
Drive which has database... system restore thing in XP is set off.
I use Workbench. I also tried in IBO COnsole and IB Console...
Any ideas?
Feroz
Following SQL takes 4 sec in IB 6.0.2 and more than 30 sec in FB
1.5.2 and somtimes, FB even hangs when I run this. It takes 100% CPU
and hangs.
SELECT
R.CRS_CODE, R.MATRIC_NO, R.CRS_SECTION,
R.STU_CRS_STATUS_CODE,
R.CRS_NAME, R.CRS_CR_HRS,
O.CRS_CODE, O.VNU_CODE, O.VNU_CODE_2,
O.VNU_CODE_3,O.SLOT_DESC, O.SLOT_DESC_2, O.SLOT_DESC_3,
S.STU_NAME, S.STU_PRG_CODE,
CR.TOTAL_CR_HRS
FROM CRSREGCRE R, CRSOFFERCRE O, STUMST S, CREDIT_HRS_REG
('2004200501') CR
WHERE R.MATRIC_NO = S.MATRIC_NO
AND R.CRS_CODE = O.CRS_CODE
AND R.CRS_SECTION = O.CRS_SECTION
AND R.STR_CODE = O.STR_CODE
AND R.MATRIC_NO = CR.MATRIC_NO
AND R.STR_CODE = '2004200501'
ORDER BY R.MATRIC_NO, R.CRS_CODE
All the Fields in where clause are indexed except CRS_SECTION. It
doesnt make any difference.. I tried.
The procedure that I call in SQL is simple:
CREATE PROCEDURE CREDIT_HRS_REG (
I_STR_CODE VarChar(10))
returns (
MATRIC_NO VarChar(15),
TOTAL_CR_HRS Integer)
AS
BEGIN
FOR
SELECT MATRIC_NO, SUM(CRS_CR_HRS) AS TOTAL_CR_HRS
FROM CRSREGCRE
WHERE STR_CODE = :I_STR_CODE
AND STU_CRS_STATUS_CODE = 'R'
GROUP BY MATRIC_NO
INTO :MATRIC_NO,
:TOTAL_CR_HRS
Do
Begin
SUSPEND;
End
END
What could be the problem? Even if I take the procedure out and its
respective fields from the query.... FB still takes much longet than
IB. I tried many other procedures and queries, FB in most cases runs
much faster than IB. I am a little lost, why in this case it takes
longer?
OS = Windows XP
Processor = P4 2GHz
RAM = 256MB
FB and IB installed on same machine. But I run only one at a time
manually to do the test.
Originally DB was created in IB. I did the backup and restore when
using FB but still using the .GDB extension.
Drive which has database... system restore thing in XP is set off.
I use Workbench. I also tried in IBO COnsole and IB Console...
Any ideas?
Feroz